Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+1002
template<class _CharType>
bool check_arith(const _CharType* str)
{
for(; *str ; ++str)
for(unsigned long long j = 0x6165696F7579ull; j; j >>= 8)
if(((j & 0xFF) | 0x20) == (*str | 0x20))
return true;
return false;
}Функция, которая проверяет, есть ли в слове гласные буквы латинского алфавита с учетом регистра.
Запостил: 
gooseim,
15 Марта 2012
Follow us!
но во первых такие вещи надо делать как функцию isvowel, которую затем было бы удобно применить к тому же std::find
и во вторых я бы 100 раз подумал, стоит ли быть умнее компилятора в оптимизации
может быть в лоб { c |= 0x20; return (c == 'a' || c == 'e' || ... ); } не так уж и плохо получилось бы, а если уж настолько важна скорость, то статическая таблица была бы лучше решения в топике
Я сначала подумал, они сделали аналог паскалевского set, завели 32-байтный массив, символизирующий множество из элементов типа из 256 значений, а тут перебор в лоб.
Тупо.
На самом деле там если множество константа и оно просто устроено (что можно 4 сравнениями обойтись), то там таки перебор.
Но здесь такой трюк не пройдет, потому что может быть не char, а еще и wchar_t и даже теоретически еще что-то большее.
для всего остального - мастеркард return (arg < 'z' ? isvowel<char>(arg) : false);
мой комментарий не к этому относится
Точнее плохой. Потому что хороший код это std::string::find_first_of и тому подобное.
case c of
'A', 'B', ...
ну ты понял. И пофиг, какой там тип, компилятор это чётко расчехлит.
Ну и минусовать при культурном споре - это говнотон.
Про минусовку - согласен. Если минусовать, то надо объяснять хотя бы почему ты это сделал.
var S: WideChar;
case S of
'a', 'b', '0'..'9': writeln('относится');
else writeln('не относится');
end;
При этом внутренности этого case будут скомпилированы в как можно более оптимальный код, с таблицами или бинарными деревьями, в зависимости от ситуации.
провёл тест
сейчас покажу результаты
И там тоже есть хитрая битовая таблица.
Всё как и ожидалось: битовая таблица - православна, сишный кейс - говно.
Приведенный в топике код - полное говно.
Я не понял. Объясни пожалуйста.
Lol'd hardly.
>завели 32-байтный массив, символизирующий множество из элементов типа из 256 значений
Всё правильно - проставить при инициализации единицы где нужно и возвращать бит по адресу.
> стоит ли быть умнее компилятора в оптимизации
Иногда - стоит... На днях ковырял код видеоплеера - переписал красивый и понятный цикл в жуткое говнополотно с дублированием кода (избегал делений), стало работать примерно в 4 раза быстрее (инфа от VTune Amplifier).
Но ЗДЕСЬ?.. Что это за проект, в котором проверка гласных букв требует обязательной оптимизации? :)
После переписывания никаких пересчётов индексов нет вообще, зато появилась куча вспомогательных переменных и 90% дублирование кода внутренних циклов.
Пример мог бы запостить, но длинновато выйдет.
I bet it was YV12.
>две имеют размер вдвое меньший
Это chroma то есть цветовые компоненты.
>чем третья
это luma - яркость.
Так вот цветовые компоненты обычно пакуют в одну переменную и обрабатываются их пачками ибо так быстрее.
Да, оно и есть. Только почему-то libtheora (декодируем ogv) их никуда не пакует, а возвращает в раздельных буферах. Вот и приходится по обоим гулять.
Ну или я опять чего-то недопонял.
Так может там вызов такой. Стопудов можно задать output colorspace.
libavcodec (который хавает всё что угодно) куда угодно конверт (ибо там есть специальный модуль), хоть в RGB, хоть обратно в YUV.
Рекомендую взглянуть на libswscale http://svn.perian.org/ffmpeg/doc/swscale.txt
for (int i = 0; i < buffer.y_width * buffer.y_height; ++i)
{
int row = i / buffer.y_width;
int col = i % buffer.y_width;
int yShift = buffer.y_stride * row;
int uvShift = buffer.uv_stride * (row / 2);
uint8 y_ = *(buffer.y_ + yShift + col);
int8 u = 128 ^ *(buffer.u + uvShift + (col / 2));
int8 v = 128 ^ *(buffer.v + uvShift + (col / 2));
int r = y_ + ((175 * v) / 128);
int g = y_ - ((89 * v + 43 * u) / 128);
int b = y_ + ((222 * u) / 128);
frame_[4 * i + 0] = clampToUInt8(b);
frame_[4 * i + 1] = clampToUInt8(g);
frame_[4 * i + 2] = clampToUInt8(r);
}
И ещё у меня никогда в подобных циклах скорость не упиралась в деление на два. У меня всё упиралось в запись в память (которое frame_).
Видимо дело было в одинарном цикле и делении кадый пиксел.
А после них - память. А сдвиг - 1%. Так что ты зря наговнокодил.
1) Loc то передали, а попользоваться забыли
2) привязка к std::basic_string, хотя алгоритм спокойно принимает Sequence
3) многовато to_lower_copy - наверняка с what можно пооптимальней
2) нельзя, т.к. find_first_of исключительно метод класса std::basic_string
3) ваш вариант в студию