Я думал может есть какой-то адвансный метод для СИ. Похоже нет, разве что asm вставки.
Во-первых, тема называется "Алгоритмы получения последнего символа в строке". Во-вторых, размещена она в разделе "Алгоритмы и математические задачи". Каким образом это связано с языком C? То, что вы при этом думали, доступно разве что победителям "битвы экстрасенсов", но никак не обделенным телепатическими способностями программистам-завсегдатаям этого клуба.
Во-вторых, в языке C просто
отсутствует стандартный строковый
тип данных (поскольку разрабатывался он совершенно для других целей), поэтому сам предмет обсуждения отсутствует как таковой; можно разве что говорить о
массиве литер, терминированном нулевым байтом, который используется за неимением лучшего.
В C++ на уровне библиотек уже появляются более функциональные варианты, как
string из Стандартной Библиотеки C++ или
CString из библиотеки MFC; есть и другие варианты, в которых низкоуровневые детали реализации содержимого строки могут отличаться.
В древнем Borland TurboPascal'е для хранения коротких строк (<=255 литер) использовался массив, первый байт которого хранил длину строки, а остальные - ее содержимое; таким образом, для определения размера строки не было необходимости перебирать ее всю политерно в поисках нулевого терминатора (которого, кстати, там и не было за ненадобностью).
Мораль: бессмысленно говорить об алгоритмах работы с абстрактной строкой - это "сферический конь в вакууме" (в том же Ruby эта задача решается совершенно те так, как в C). Имеет смысл лишь
конкретная реализация для
конкретного языка. Вот, скажем, определение длины нуль-терминированного литерного массива - предмет вполне конкретного разговора (за исключением того, что в функциях стандартной библиотеки C работа с такими "строками" давно уже реализована производителем компилятора в лучшем виде, и "оптимизаторам" ловить там совершенно нечего).
В-третьих, ассемблерные вставки нужны здесь (в данном конкретном случае "строк" на C), как зайцу стоп-сигнал, поскольку используется типичная работа с указателями, под которую язык C заточен максимально эффективно, и подобные медвежьи услуги компилятору в итоге обычно только ухудшают код, поскольку мешают оптимизации. И еще любопытно узнать, на ассемблере
какого именно процессора они будут написаны; будет ли, к примеру, поддерживаться архитектура ARM? В погоне за мифическим ускорением полностью теряется основной и на сегодня чуть ли не единственный козырь языка C - портируемость кода.
PS
2Dale. Да я скопирывал код с того же сайта. И?
Да кто бы сомневался... Этот неподражаемый стиль узнать было нетрудно, пролистав там пару-другую статеек. Перефразируя классика, "все красивые программы похожи друг на друга, каждая кривая программа крива по-своему".
как Вы считаете копи-паст с одного сайта на другой вообще может повлиять на какие-либо рейтинги поисковика?
Вы притворяетесь или действительно не понимаете разницы между копипастой и
ссылкой? Лично я ее кликнул, сначала из интереса (ну мало ли, вдруг там какие-то тонкости работы с декораторами, которые я упустил), потом еще несколько статей проглядел, уже чисто поржать. Так что невинность симулировать тут особо нет надобности - и посещаемость у сайта клуба не так мала, чтобы счетчик переходов накрутить, и в индексы ссылка просочится, поскольку ее не везде еще модератор поправил.
Поэтому давайте вести честную игру: пришли в клуб прояснить интересные для себя вопросы - добро пожаловать, задавайте, поможем, чем только сможем (только
задавайте их, а не вынуждайте угадывать, что же вам действительно нужно). Пришли попиарить творение юных кулхацкеров - здесь такое без надобности, кнопку выхода с форума найдете без труда.