- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <iostream>
}
void main (){
int prog=0,n;
printf ("Which programm? ");
scanf ("%d",&prog);
if (prog==1){
int glas=0,sogl=0,j=0,k=0;
char *s,*l,*m;
s=(char*)calloc(20,sizeof(char));
l=(char*)calloc(20,sizeof(char));
m=(char*)calloc(20,sizeof(char));
flushall();
printf ("\nEnter text: ");
gets(s);
n=strlen(s);
/*Разбиваем на два массива исходную строку*/
for (int i=0;i<n;i++){
if(s[i]=='a'||s[i]=='q'||s[i]=='e'||s[i]=='y'||s[i]=='u'||s[i]=='i'||s[i]=='o'||s[i]=='j'){ l[j]=s[i]; glas++;j++;}
if(s[i]=='g'||s[i]=='f'||s[i]=='d'||s[i]=='s'||s[i]=='p'||s[i]=='t'||s[i]=='r'||s[i]=='w'||s[i]=='h'||s[i]=='k'||s[i]=='l'||s[i]=='z'||s[i]=='x'||s[i]=='c'||s[i]=='v'||s[i]=='b'||s[i]=='b'||s[i]=='n'||s[i]=='m'){ m[k]=s[i];sogl++;k++;}
}
printf ("\nDivided:\n");
puts(l);puts(m);
/*Сортируем каждый массив*/
char c=51,d=11;
for(j=0;j<sogl;j++) {for (int i=0;i<sogl;i++){if (m[i]>m[i+1] && (i+1)<sogl){d=m[i+1]; m[i+1]=l[i]; m[i]=d;}}}
for(j=0;j<glas;j++){ for (int i=0;i<glas;i++){if (l[i]>l[i+1] && (i+1)<glas){c=l[i+1]; l[i+1]=l[i]; l[i]=c;}}}
printf ("\nFinal:\n");
puts(l);
flushall();
puts(m);
}
Источник: http://otvety.google.ru/otvety/thread?tid=78a81d7ac11a8804&table=/otvety/topics?clk=lftpn&tab=wtmtosb
Цитата: "Задача: Написать программу для обработки строки следующим образом: вначале должны идти гласные буквы, упорядоченные по возрастанию (aaeeiioo), затем согласные, упорядоченные по убыванию.
Написал программу, она нормально сортирует гласные, но когда переходит к согласным - совершенно не работает."
Follow us!
http://lukeplant.me.uk/blog/posts/why-learning-haskell-python-makes-you-a-worse-programmer
Ну и рассказал кулстори про терки с каллегами из-за того, что автор стал везде пихать функциональный код в нефункциональном языке.
К слову C# сейчас стал более функциональным, будь то var или лямбды без необходимости писать delegate в каждой. Да и каллеги стали попрошаренее.
Без создания ненужных лямбд + более быстрая классификация, нормальное форматирование. Если не делать супер-портабельным, то хеш-таблицу можно записать буквально, вместо того, чтобы создавать динамически, но это так на так получится. Можно использовать case вместо таблицы, но зависит от конкретного Лиспа. Многие оптимизируют case лучше, чем таблицу, но некоторые тупо перебором сделают.
P.S. Форматирование не трожь! Оригинальный tirinox-style, на зло всем. ;-)
Макросы нужно компилировать, чтобы они хорошо работали. Ну и тест сделаный на основании одной тестовой строки? Да и кроме того, у вас не все гласные перечислены?..
Про гласные, да, я внизу поправил.
Про тестовые условия, ну, я ж строку не подбирал, чтобы она у меня быстрее работала.. и как-то лениво было всеобъемлющее исследование проводить ради комментов в говнокоде )
И что, что вы строку не подбирали? А то, что в ней нет прописных букв вообще? А то, что в ней есть символы из (возможно) недопустимого диапазона? Тест левый вообще и ни к чему не обязывает.
P.S. У меня SBCL, а убеджал человек, которому я склонен верить...
Есть стандарт, который описывает как код должен работать, стандарт нигде не предписывает как компилятор должен инлайнить чего-то, или как он должен оптимизировать код полученый из макросов, и т.п. Все остальное - вымысел или, в лучшем случае - домысел. Даже если указать в декларации, что функцию нужно заинлайнить - это только рекоммендация, и если компилятор не умеет, или посчитает лишним - то и не сделает.
Наглядно, кратко, и работает быстрее этих ваших лиспов даже в ghci, я молчу про то, как оно будет работать при нормальной компиляции с -O2.
"aaaaaeeeeiiiiiioooouywwvtttttssrrpnnnnn nnmlllkhhhgfddc"
(0.01 secs, 2959140 bytes)
Да собственно ни к какому, так же как и по вашему коду, и коду trinox.
Я просто пришел и насрал в уютном клубе лисперов, которые, между прочим, первые начали мериться таймингами кода, даже не зафиксировав условия задачи перед тем как ее решать.
> в строке предположительно есть и прописные буквы
А еще там предположительно есть пробелы.
Но идея была неплохая... :)
Новое боевое искусство!
Нужно вдумчиво прочитать код, для того, чтобы понять, почему его больше, чем в других примерах.
Я к сожалению не смог добиться от Питона хорошей оптимизации кейса. Возможно есть смысл посмотреть в сторону Алегро или CCL. Или попробовать допилить Питон специально под этот случай (но это очень много работы).
Но из этого явно не следует, что решение с использованием хеш-таблицы будет обязательно лучше, т.как реализация таблицы - скорее всего бинарное дерево, и бинарный поиск по упорядоченому массиву эквивалентен поиску по такой хеш-таблице.
Хеш-таблица на то и хеш-таблица, чтобы состоять из хеш-функции и массива. Время поиска складывается из времени хеширования значения и 1 или нескольких выборок из таблицы. При низком к-те заполнения и хорошей функции выборка будет всего лишь одна.
P.S. Если в библиотеке лиспа бинарное дерево назвали хэш-таблицей, то впизду такие лживые библиотеки.
Я вспоминаю треды, где wvxvw разглагольствовал о правильности парадигм на основе своего незыблемого опыта и тут вдруг такой вброс.
Not all hash tables use a linked-list as a bucket. A popular alternative is to use a "better" bucket, for example a binary tree, or another hash table (with another hash function), ...
Мне когда-то попадалась статья про trie где были результаты тестов и сколько времени занимают какие операции в хеш-таблице по сравнению с ним и с бинарным деревом. И для данных, которыми могут оперировать ПК с типичными на сегодня объемом памяти - разница между хеш-таблицей и бинарным деревом практически никакая (удаление из хеш-таблицы правда, дороже).
Ну неправда. Если бы так было - сложность бы записывали к примеру как O(log(n)), зачем себя обманывать?
Для реализации со списками:
Трудоёмкость операций в хеш-таблице зависит не от числа элементов n, содержащихся в ней, а от коэффициента заполнения α. Оценку трудоёмкости можно записать, как O(1+α/2) А большие load-factor'ы никто никогда не ставит, разве что недалекие люди, которые думают, что так сэкономят память.
По краткости лучше не получается
Как, и будет ли это быстрее, например в CCL на ARM? - хз. Разница между тестами маргинальная, но есть какие-то общеизвестные трудности при реализации чего-то. SBCL смог хорошо заинлайнить лямбду, а какой-нибудь друой лисп не смог бы этого сделать, и получили бы штраф за вызов функции, и т.п.
Интерестно, что это будет даже медленнее работать, чем если тут же заменить хеш-таблицу на список. Вариант со списком будет работать примерно так же, как и предыдущие (но экономнее расходует память).
tirinox
Могли бы и не делать такую глупую ошибку. Вы забыли удалить лишние символы из строки, например знаки припинания, так как они не относятся ни к гласным ни согласным.
http://liveworkspace.org/code/2jTjqt$24
Знаю как написать оптимальнее, но мне лень, пока код не учавствует в бенчах.
>гласные буквы, упорядоченные по возрастанию (aaeeiioo), затем согласные, упорядоченные по убыванию
Он скобки забыл
http://liveworkspace.org/code/2obWBt$1
А вы ещё на лисперов гоните. Среди хаскелистов одни идиоты.
Решения, естесственно, можно оценивать с разных позиций. Так вот, изначальное решение на CL, как и все последующие решения на Хаскелле, (возможно, за исключением тех, где используется partition - хотя, я не знаю, как именно оно реализовано, так что может и нет) принципиально выигрывают за счет того, что при маленьком n выполняется "n примерно равно log n примерно равно 1". Естесственно, если мы попытаемся расширить алгоритм и сделать его более универсальным, для последовательностей произвольной длины (например, захотим с его помощью реализовать регулярные выражения для строк в Юникоде). То все эти решения обламаются - потому что, чем болше будет n, тем быстрее будут работать варианты, где классификация делается за n или n log n время, вместо n^2.
Все тормоза в этих алгоритмах будут в сортировке, которая займет O(n*log(n)), где n - количество символов в строке.
> например, захотим с его помощью реализовать регулярные выражения для строк в Юникоде
Вы не в ту сторону копаете. Количество букв во всех земных алфавитах вполне конечно, в отличие от длины строки, которая как раз произвольна. Поэтому в асимптотике насрать на то, ищем ли мы китайские иегроглифы состоящие из трех черт, или всего лишь 5 гласных букв. Это влияет только на константу. Захочется уменьшить константу - ок, заменяйте на хеши, мапы, или что там будет быстрее.
тут, в большинстве случаев имеем дело с m * n, где m - количество символов в вводе, и n - количество символов в категории, котоую нужно отфильтровать. В общем случае это n^2. И именно поэтому проигрывает не на константу, а в квадрате.
> Количество букв вполне конечно
Вот только когда мы говорим о Юникоде, где символов имеется 0xFFFFFF или что-то в этом духе, то это становится вполне себе соизмеримо со строками, с которыми эта функция будет работать.
'n' ^ 2 = 'p'
З.ы. таблицы под рукой нет, считал в уме, могу ошибиться...
Ок, 0xFFFFFF это примерно 16млн. Значит в наивной реализации константа составит 16млн, в более разумной с деревом или бинарным поиском - всего 24, битмаска же на 16млн элементов даст константу 1 (т.к. в типичном тексте, даже китайском, используется лишь маленькая часть всех символов юникода, то используемый кусок битмаски поместится в кеш, и доступ будет очень шустрым). С константой разобрались, теперь перейдем к O(n^2).
Видя сложность O(n^2) резонно предположить, что 200 символов будут обрабатываться в 100 раз дольше, чем двадцать. Но... это же не так. 200 символов будут обрабатываться всего в 10 раз дольше чем 20, даже при самой-самой наивной реализации (`elem` многоМногоБукв), с этим то вы спорить не будете? А это и есть сложность O(n).
P.S. Не разбирались с теорией сложности вычислений - не трогайте ее, это вам не цирк, где можно безнаказанно жонглировать определениями.
А откуда такие предположения сразу о том что именно будет в тексте? А если это не китайский, а японский учебник арабских математических терминов? И вообще, какое это имеет отношение? В общем случае есть последовательность с доменом неопределенного, но возможно очень большого размера. Естесственно, в конкретной задаче об этом не говорится, поэтому, я не настаиваю на том, что более общее решение лучше. Я только говорю, что нужно иметь в виду, что решение предпочтительно только тогда, когда домейн очень ограничен.
> Но... это же не так.
Откуда инфа? Есть множество накладных расходов помимо непосредственной задачи. Тета или биг-О задают только верхний предел. А то, что случайно может получится быстрее - ну так повезло.
Худшее время классификации каждого символа (Tbad) нам известно заранее, оно зависит только от алфавита и от алгоритма выбора категории по символу, и никак не зависит от входной строки. Входная строка (длины n) пробегается ровно 1 раз. Значит худшее время классификации составит Tbad*n. А это и есть O(n). Не нравится? Ну так докажите обратное, что время в худшем случае составит Tbad*n². Докажете - я поверю, что там O(n²). Нет - слив засчитан.
Tbad хоть как-то зависит от длины строки? Нет. Значит вы не имеете права дописать еще одну n к сложности данного алгоритма.
m - размер алфавита
n - количество символов во входной строкеЯ утверждаю, что внутренний цикл всегда выполняется за время, зависящее только от m, но не от n. При фиксированном m (а во время классификации одной строки оно фиксировано, т.к. никто не меняет категории во время классификации) это время константное.
Процитирую вас:
> тут, в большинстве случаев имеем дело с m * n, где m - количество символов в вводе, и n - количество символов в категории, котоую нужно отфильтровать.
Бесспорно! Здесь я полностью с вами согласен!
> В общем случае это n^2.
А вот это, простите за выражение, хуйня. Это все равно что утверждать, что вон тот код, который я привел в этом комменте, выполнит m*m итераций, а не m*n.
Иными словами, O(m*n) линейно как относительно m (при неизменном n), так и относительно n (при неизменном m).
Я правильно понимаю?
Квадратичная сложность будет только если значения параметров прямо пропорциональны друг другу, что в общем случае совершенно необязательно так.
Иначе говоря, O(m*n) = O(n^2) тогда и только тогда, когда m = const*n
Все верно.
Я не говорю, что наивная реализация через (`elem` "aeiou") предпочтительна, или даже эффективна. Я утверждаю только то, что классификация даже с такой хуевой функцией - O(n), а не O(n^2).
Да, можно взять двоичный поиск или двоичное дерево, и получить меньшую константу перед O(n).
Да можно взять битмаску, и получить еще меньшую константу.
А можно написать код на асме, и выиграть в константе еще в 10 раз, и все равно останется то же самое O(n).
Поймите, было бы там O(n^2) - время бы росло на 2 порядка на каждый порядок в n. Т.е. при росте строки с 20 до 200 символов время бы выросло в 100 раз. Но это ведь не так. Время растет линейно с ростом длины входной строки.
Думаю, что для данного конкретного случая, пока символов не много - этот способ эффективнее хешмапы или любых других сложных структур данных, особенно если бы хаскель умел представлять "aeiou" как массив, а не как список с плохой кешфрендлявостью.
Обращение к большой битмаске потребует загружать новую кешлинию в кеш, замещая старые полезные кешлинии, на каждой итерации цикла. В то время как маленький массив из пары согласных букв не потребует подгружать новую кешлинию, а как ты знаешь, подгрузка кешлиний самая медленная операция у процессора.
А в каком-нибудь языке с большим алфавитом, например в китайском, вообще гласных нет. Как ты тогда свою слишком универсально поставленную задачу будешь решать?
И подозреваю, что isLetter в хаскеле возвратит true только для символов из установленных в системе локалей.
Дает нам:
В более 6 раз быстрее, чем первое мое :)
> @wvxvw: Попробуйте сократить вашу тестовую строку до одного символа - так еще быстрее будет.
Ненене, Девид Блейн, пусть он удлинит строку раз в 10. Тогда этот метод начнет обгонять все перечисленные выше. И чем больше будет строка - тем сильнее. Почувствуйте силу асимптотики.
Но, я думаю, главная идея ясна.
Это примерно в 4 раза оптимальнее по памяти, и если переписать incf так, чтобы он не прибавлял знаковые целые с fixnum, то по времени будет так же.
чет я устал как-то совсем :(
Респектос, 0.027 seconds of real time на том же тесте.
Но версия на Си, все равно в 10 раз выигрывает. (Не принимая во внимание, как там что где компилирует или нет).
Ну не надо сравнивать по скорости Си с функциональными языками. Си всегда выиграет такое соревнование. У ФЯ есть шанс победить в понятности и скорости разработки, да и только.
С корнями, логарифмами и делениями? Ну так тут и интерпретатор может сравняться по скорости, т.к. эти операции спокойно могут выполняться дольше чем весь управляющий циклом обвес... Но вот обогнать си при одинаковом алгоритме - очень маловероятно.
> Си-Шарп вообще всрался и програл Лиспу
Емнип он даже медленнее жабы...
И еще. Говоря о Сях(++). Их еще нужно уметь использовать (это справедливо в той или иной степени для всех языков, конечно). Алгоритмы уже реализованные в ф.языках зачастую во много раз быстрее на-коленке-самописных и даже быстрее вроде-бы-отточенных-библиотек. Год назад сравнивал встроенный BigNum в лиспе с одним моим вариантом BigNum и 2-3 разными сторонними либами. И лисп вышел победителем.
В сети есть результаты сравнения по скорости решений разных классов задач на разных языках. И функциональные языки там показывают себя весьма достойно.
Впрочем вопрос спорный, да.
В лиспе бингнумы быстрее, чем в GMP?
> Алгоритмы уже реализованные в ф.языках зачастую во много раз быстрее на-коленке-самописных
Безусловно, а еще они корректнее и отлаженнее чем самописные велосипеды. Поэтому велосипеды - для души, а в продакшене лучше лишнюю либу зацеплю.
> все эти приблуды ФП сжирают не колоссальное время
Смотря какие... вызов лямбды вполне инлайнится, хаскель тоже так умеет. А вот если эту самую лямбду передать аргументом - то уже не факт, что что-то оптимизнется. Тут надо быть осторожным.
До него тогда руки не дошли или плохо гуглил.
Чтобы иконку нарисовать? Ну да, ну да, не фотошопом же...
Извиняй, GIMP каждый день глаза мазолит, а GMP пользуюсь только в составе других языков или библиотек, тк интерфейс у него пrативный.
К сожалению, каждый язык имеет свою область применения. Я хотел бы иметь один удобный везде, но не судьба. Реальность такова, что в большинстве задач вполне хватает "домохозяечных" (это ведь не о C/C++, верно?) императивных языков. Более того, код получается даже проще и быстрее. Да, не хватает некоторых фишек вроде лямбд, но в конечном счёте и без них вполне можно жить. Если хорошенько подумать, всегда можно написать хороший код.
А вот если бы я взялся писать компилятор типизированного диалекта lisp под llvm (моя давняя задумка, жаль, руки не доходят), я бы выбрал для этого Haskell, не сомневаясь ни секунды.
Очевидно, я не имею ничего против функциональных языков. Я даже обоими руками ЗА. Но примеры CL в этом треде наводят меня на мысль, что уж лучше пусть будет c++.
Как ты себе это видишь? Это же вся суть лиспа, что он динамически типизированный. А если нужен статически типизированный лисп - бери хаскель. Помоему выбор очевиден.
Видимо Роман хочет что-то среднее между хаскелем и лиспом - со скобочками и макро, но при этом с выводом типов.
Есть прецеденты
> Роман хочет что-то среднее между хаскелем и лиспом
Да, именно. Хотелось бы получить лучшее из обоих миров. Изящный лисповый синтаксис и гигиеничные макросы, строгая типизация с выводом типов, функциональные ленивые последовательности, "протоколы" === typeclasses, сопоставления с образцом, иерархическая система модулей... компиляция в натив, автоматическая оптимизация от llvm, годный FFI, примитивы многопоточности и асинхронного программирования. Такой лисп (а не дурацкий CL) завоевал бы моё сердце.
Да и вообще сам CL, хоть мне и нравятся его концепции, но он имхо представляет из себя типичную исторически сложившуюся помойку, по стилю напоминающую PHP.
В остальном да, интересная идея.
Так и есть, но есть же Scheme R5RS.
Начиная с R6RS они уже начали упарываться по оптимизации, превращая язык в раздутую продакшен конструкцию, хоть и во благо.
> гигиеничные макросы, строгая типизация с выводом типов, функциональные ленивые последовательности, "протоколы", сопоставления с образцом, иерархическая система модулей... компиляция в натив, автоматическая оптимизация от llvm, примитивы многопоточности и асинхронного программирования.
Это вы сейчас так мягко намекаете на Nemerle? Добро.
gccшные nested functions и прочие лямбды с замыканиями удобны чтобы не городить указатель на функцию(С), класс-функтор(С++), анонимный класс (Java).
Весь профит, как по мне в захвате параметров, которые не нужно передавать аргументом. То есть лямбды для меня не модная абстрактно-функциональная самоцель, а средство упростить код.
>Ох уж мне этот функциональный энтузиазм...
Хороший, взвешенный коммент.
Вон попробуй на хаскеле реализовать задачу, которую мы тут обсуждаем, но не через тормозные списки n log n, а через сортировку подсчеом n. Тут же элегантный хаскель код превратится в уёбищное говно и по количеству кода и читабильности сразу проигрет сишке. Ну и по скорости тоже проиграет чуть-чуть.
Безусловно. И vwxwv тут не докопается, ибо даже при огромных алфавитах в 4 гигасимвола log2(m) это всего лишь 32.
Так что не все так ужасно, хотя, согласен, совсем не идеально...
P.P.S. В хаске есть мутабельный массив, но тут надо еще подумать, как прикрутить его к фолду.
Да знаю что он есть, но к фолду его не прикрутишь. Он же работает как ввод-вывод в файлмассив на монаде IO.
Ну и зачем тут массив? Тут std::deque нужен хотябы по той причине, что ты описал выше. Сомневаюсь что в хаски он есть.
Это можно вызывать из чистых функций или монаду IO придется протягивать из майна? Это как-то не красиво, да и функциональный код превращается в императивный.
Приглашаю поучаствовать в соревнованиях нашей специальной олимпиады. Код вы уже почти написали.
Unboxed быстрее, потому что в нём хранятся сами значения цельным куском, а в обычном — только ссылки на них, по которым нужно ещё пройти. Но это возможно только для некоторых типов (в основном примитивных типа Int и Word разного размера).
Гляну...
http://liveworkspace.org/code/1WGydL$77
Работает только с латинскими lowercase символами в непрерывной упорядоченной кодировке.
O(n) - затраты памяти, хотя возможно из-за ленивости они будут O(1). Возможно чтобы получить О(1), код нужно поправить, чтобы хвосты не удерживались.
O(n) - алгоритмическая сложность.
Вот я правда не знаю, нужно как-то strict добавить, а то стек может начать разрастаться.
Этож не diff array.
А его можно без особых переделок применить в коде сортировки с массивом?
Надежды нет...
Data.Array.Diff совсем пропал...
Data.Array.Unboxed тоже ничего не получается...
Читал про них на
http://www.haskell.org/haskellwiki/Arrays
но бесполезно. Их идеи не компилируются из-за не найденного модуля.
Хотелось бы как-то так:
Может как-то через апликативные функцторы или lift?
[color=gray]Но честно признаюсь, подглядел у Лямбдабота.[/color]
http://liveworkspace.org/code/1XvuHq$21
Вроде поставил в одинаковые условия. Планирую устроить бенч вида replicate этой строки много раз.
Только блин, как убрать у всех функций из прелюдии необходимость вместо
foldl писать Prelude.foldl ? Проблема появилась после того, как импортнул Data.Map
http://liveworkspace.org/code/1XvuHq$26
Со всем согласен? Можно мериться?
http://liveworkspace.org/code/2Vf3lp$5
http://liveworkspace.org/code/1tt53n$10
Способ с мапом привел к стековерфловочке. Способ с массивом на взгляд медленноват, но вроде оверфловочки нет. Видимо действительно получилось О(n^2) из-за копирования массива каждый раз.
http://liveworkspace.org/code/2Vf3lp$6
http://liveworkspace.org/code/1tt53n$11
Но по идее надо поиграться со строгостью, а то он походу ничего не делает пока не дочитает строку до конца.
http://ideone.com/aTR6o2
Конечно, хреново тестированный и со скрипом скомпиленный.
Не соизволите ли вы оформить ваш код для бенчмарка?
З.Ы. В задании ни слова о порядке букв в кодировке.
З.З.Ы. static unsigned long counts - нехорошо, наверн, глобальной то делать, хотя опять же ни слова в задании.
З.З.Ы. Память не жрет, потому как срет в stdout. 4 Гб буду высираться до конца следующего калаендаря Майя.
Вы так говорите, как будто ваша программа жрет память, но не будет срать в stdout.
Я немного не то имел в виду про stdout, а то, что мол одно зло променяли на другое.
Хуяссе константно. Это между прочим линейное O(n).
stdout не зло. Программа в любом случае должна выводить. Ваша тоже выводит. Разве что у Романа она чаще дрючит putchar, что, впрочем, не страшно, т.к. там все равно есть буферизация, и оно будет ненамного медленнее, чем мутить свой буфер.
Да, для одной строки может и линейно, а для 10000 строк достаточно уж выделить один буффер максимальной длины в начале и довольно, как я это и сделал. Другой вопрос, если задача встанет: вот вам ОДНА гигабайтовая строка, дерзайте. Вот Роман с расчетом на это и сделал, видимо. И это согласуется с начальным говнокодом.
Но мне уже в треде с лиспом взбрело в голову делать тест на 10000 мелких строк, так я и тут продолжил эту линию, чтобы затем сравнивать в почти одинаковых условиях.
В конце концов, все сводится к условиям задачи и критериям оценки. Что вы хотите? Быстро, читабельно, универсально, портабельно, минимум кода, минимум потребления памяти? Не все сразу.
Тогда качество ваших бенчмарков вызывает ха, хаха.
Мерить там нечего: один символ строки - один доступ по индексу и инкремент. Ни линейных поисков, не выделений памяти. Быстрее не напишешь, да и не нужно.
С минимальнымм усилиями по жонглированию входными/выходными буферами можно сделать из этого подпрограмму, но я не вижу в этом смысла.
> В задании ни слова о порядке букв в кодировке.
Именно поэтому нужно быть осторожным. Буквы могут идти не по порядку.
Надеюсь, я не доживу до того, когда в ASCII кто-то аглийские буквы начнет переставлять.
Но вообще, очевидно, можно допилить до универсального в этом плане состояния.
> Надеюсь, я не доживу
http://ru.wikipedia.org/wiki/EBCDIC
Слава богу уже пережили.
http://xkcd.ru/i/386_v1.png