Написал небольшую книгу для C/C++ программистов

Ну, если изначально использовать инструменты, которые совместимы не только сами с собой, то ничего ехать и не будет. А так... ой, я открыл doc/docx и у меня все поехало... ССЗБ.

скопировать нужный кусочек из достойного места

Кстати, отличный способ скопировать к себе уязвимость, которую потом поправят в этой библиотеке, а ты нет.

Мне кажется ТС изрядно доставляют неформальная ЛОРовская фауна и срачи в комментариях, иначе я не понимаю почему он до сих пор здесь, учитывая то количество говна, которое на него льется (иногда по делу, но по большей части — нет)

При наличии SSD, i7 и 32 Гб оперативки молниеносно работать будет любой код. xD

Если так, мне кажется, что-то сильно не в порядке с тем, как этот цикл реализован в компиляторе. Хотите скорости - пишите на ассемблере.

Что-то сильно не в порядке у людей, которые в матчасти не секут, но мнение имеют.

1. Не все люди больны. Именно поэтому помимо ассемблера приходится писать быстрее на языках более высокого уровня.

2. Да, разворачивание цикла иногда может дать прирост по производительности. И не тебе, невежда, решать, когда, кому и на чём писать код драйверов, которые ОБЯЗАНЫ работать быстро, что бы ты там по читабельности не хотел в своих представлениях о хороших компиляторах.

По теме: большую часть читать не интересно, ибо многое выводится просто из собственного опыта, кое что для себя нового тем не менее подчерпнул, за это спасибо.
Пресловутый пункт 41 никуда не годится: ИМХО, следует ввести пометку, мол вендоспецифика.
Да, тащить либу ради CRC, когда функция расчета 10 строк + таблица — бред, это наравне с недавними казусами с npm и библиотеками-однострочниками, но если речь о всяких PNG, то в приоритете переносимость кода и прибивать libpng — значительно меньшее зло, чем прибивать код к винде.
Хуже только писать на VC++, вместо чистого переносимого C++

По правде сказать, почитав несколько глав я утвердился в мысли, что мекрософт провоцирует умственную деградацию.

Без обид, но всерьез обсуждать сравнение с 1 и -1 вместо < или > 0 может только полный дэбил.

И да, попытка использовать цикл без анализа частоты выполняемого кода и того, кода, который порождает компилятор, это просто безумие...

И да, попытка использовать цикл без анализа частоты выполняемого кода и того, кода, который порождает компилятор, это просто безумие...

Безумие писать неверный код. Какая разница, насколько быстро он неправильно работает.

Безумие - это наклепать кучу страниц текста рекламы проприетарного статического анализатора, нафигачить кода со ссылками на MSDN и ворваться на форум линуксоидов с криком «а вот у меня ещё твиттер есть». Блин, да я поражён как вас тут ещё не послали лесом. Вы же очевидный идеологический противник всего прекрасного местной тусовки.

В свободной стране живем!

про библиотеки забыл :)

Поправочка: язык программирования не решает _никаких_ проблем.

Поправочка: язык программирования их *создаёт*. Или нет. Зависит от языка. Вернее, его автора.

И куда проще обвинить язык в их наличии, чем стучать линейкой по всем шаловливым рукам на проекте.

Если использовать нормальный язык, всем шаловливым рукам в проекте будет стучать компилятор.

Кто читал, там все для детворы или что-то серьезное есть?

Безумие писать неверный код. Какая разница, насколько быстро он неправильно работает.

Практика, критерий истины. И она четко показывает, что идеальное ПО просто не имеет шансов, потому что для того, чтобы продукт взлетел, многие люди его должны освоить и использовать. А для этого рабочий код надо им представить как можно раньше. Поэтому пока напишется идеальный код, на рынке уже вовсю будет использоваться 3-4 версия некоего быдлокода, в котором большинство ошибок уже будет исправлено.

Если бы эта лшибка была критична, ее бы и нашли гораздо раньше.

…иначе я не понимаю почему он до сих пор здесь, учитывая то количество говна…

Реклама. Индекс цитирования.

Если что, то в РФ и на постсоветском пространстве широко распространён формат fb2

Художественная литература о С++? Это же не perl, все-таки!

Всё для.

Долистал до середины, детвора смеется :D

Какая это книга, это буклет мамкиного кодера. Читайте классику, пацаны.

Компилятор не всегда справляется, иногда (часто) ему приходится помогать.

Понятно, фтопку.

Первый же пример...

Я бы порекомендовал переписать эту функцию так:
static int rr_cmp(uchar *a,uchar *b)
{ 
  for (size_t i = 0; i < 7; ++i)
  { 
    if (a[i] != b[i])
      return a[i] - b[i];
  } 
  return a[7] - b[7];
}

Тебя ничему история с strcpy, strcmp и прочими не научила (типичная причина stack-overflow)?

Безумие писать неверный код. Какая разница, насколько быстро он неправильно работает.

Так твой вариант так же не верен без «анализа частоты выполняемого кода и того, кода, который...»

Не в тему.
Автор просто переделал пример из кода мускуля.

Да и какие нахрен векторы и прочие шаблонные контейнеры работающие поверх кучи, когда речь о высокопроизводительном софте?

Да и какие нахрен векторы и прочие шаблонные контейнеры работающие поверх кучи, когда речь о высокопроизводительном софте?

Вектор не обязан работать поверх кучи.

Спасибо. Больше литературы. Так держать. Единственное - реклама. Да вынесите Вы свой инструмент в отдельную главу, заодно и доку по нему сделаете.

При наличии SSD, i7 и 32 Гб оперативки молниеносно работать будет любой код. xD

молниеносно работать будет любой код

любой код

Увы.

Какая разница, откуда он код привел, он делает ту же ошибку по сути - в трёх разных местах напишет 7. Если завтра будет не 7, а 6, а функцию изменить забудет - всё накроется медным тазом. Если он во время написания этой функции совершит опечатку и вместо 7 напишет 8 в одном из трёх мест - всё накроется медным тазом. Если вызывающая функция создаст меньший массив, или еще веселее, кстати, передаст тупо nullptr - всё накроется медным тазом. (Да, я про проверку на nullptr в этом куске кода забыл).

Короче говоря, рекомендация автора - это самый настоящий говнокод, выдаваемый за улучшение.

Короче говоря, рекомендация автора - это самый настоящий говнокод, выдаваемый за улучшение.

Там поинт только в том, что кода меньше. Читабельность, все дела xD

Без рекламы.

Да, но зачем она тогда мне. :))

Мягко говоря твоя книга явно не для тех кто уже начал осознанно пользоваться статическими анализаторами кода и понимает зачем им это нужно. Это как в детском саду рекламировать презервативы.

Не понимаю зачем её вообще запихали в мининовость?

Еще раз, это in-place улучшение конкретного отрывка кода.
Перекраивание архитектуры мускуля глобально по вашим диванным бредням — совершенно отдельная тема для разговора.

Окей, не обязан, просто в голову первым делом пришел std::vector.
В любом случае, рантаймовым проверкам выхода за границы не место в хайлоад продакшене.

рантаймовым проверкам выхода за границы не место в хайлоад продакшене.

Рантаймовым проверкам выхода не место в критических или глубоко вложенных циклах. Во всех остальных местах они уместны, хайлоад или нет.

P.S. хайлоад - это много-много серверов с похапе.

Не вижу препятствий, если код покрывается тестами и отсутствие бажных входных данных гарантировано.
А вот впихни проверки в хайлоад в каждом цикле над массивами и контейнеры заместо оных массивов и пусть клиенты наслаждаются скоротечным течением сакуры, которое пройдет быстрее, чем их запросы к твоей БД.

диванным бредням

Это опыт. Я очень много видел проблем именно из-за такого кода.
Хочешь in-place, минимальными жертвами? Пожалуйста. Одной строки достаточно.

static int rr_cmp(uchar *a,uchar *b)
{
  // arrays are expected to have more, then 8 elements
  // if not, we're in deep shit.
  const size_t LAST_IDX = 7;
  for (size_t i = 0; i < LAST_IDX; ++i)
  { 
    if (a[i] != b[i])
      return a[i] - b[i];
  } 
  return a[LAST_IDX] - b[LAST_IDX];
}

У оператора [] нет проверки выхода за границу.

В чем различие, кроме отсутствия магических чисел?
Тут я не спорю: магические числа это плохо.

Не вижу препятствий

Ну окей.

А вот впихни проверки в хайлоад в каждом цикле над массивами и контейнеры заместо оных массивов и пусть клиенты наслаждаются скоротечным течением сакуры, которое пройдет быстрее, чем их запросы к твоей БД.

Хайлоад, массивы, БД... какие-то эротические сны школьника.

Аргументация у тебя сегодня на высшем уровне :)

В их отсутствии, очевидно. Я бы сделал еще лучше - ввел новую функцию:

static int rr_cmp_n(uchar *a,uchar *b, const size_t LAST_IDX)

которые в матчасти не секут

Допустим. Это оправдывает компилятор, не способный делать оптимизацию, из-за чего приходится писать индусский код?

Аргументация у тебя

Аргументация бывает в спорах. Спорить с тобой не о чем - ты просто излагаешь то ли городские мифы, то ли свои фантазии.

Опять же, высосано из пальца.
Мы говорим в контексте конкретной статьи о примере кода, взятом из БД, которая является как бы чувствительным к минимальным задержкам софтом, и предлагать пихнуть туда контейнеры и проверки границ — несусветная то ли тупость, то ли ересь.

Не надо выпадать из реальности. Академический подход с максимальной безопасностью и собственной субъективной правильностью не всегда уместен.

Опять же, высосано из пальца.

mersinvald > впихни проверки в хайлоад в каждом цикле над массивами и контейнеры заместо оных массивов и пусть клиенты наслаждаются скоротечным течением сакуры, которое пройдет быстрее, чем их запросы к твоей БД.

Да, это высосано из пальца.

Не надо выпадать из реальности.

Чтобы из нее выпасть, сначала надо в ней появиться.

Разворачивать циклы - последняя стадия оптимизации, когда менеджер бьет копытом а соответствующая опция компилятора не сработала

Да, это высосано из пальца.

Кто-то не умеет в гиперболы?

Чтобы из нее выпасть, сначала надо в ней появиться.

Первая дельная мысль с твоей стороны

Oh, shit, да что вы говорите? Т.е. вы, как и Карпов, считаете что джуны в скуле настолько тупы, что даже не знают что на Земле существуют лупы, а развертку сделали от невежества? Ай-яй-яй, ну и дегенераты...

Кто-то не умеет в гиперболы?

Кто-то умеет только в гиперболы.

вы, как и Карпов, считаете что джуны в скуле настолько тупы, что даже не знают что на Земле существуют лупы, а развертку сделали от невежества?

Я, как и Кнут, считаю, что преждевременная оптимизация - корень всех зол.

А вы этот конкретный код анализировали? М.б. именно эта разветка – результат долгих и кропотливых тестов и стараний целой команды.

Конечно нет, зато кричать что все мудаки, один поциент Д'Артаньян — сама суть диванной аналитики)

Но... ведь.. это был сарказм...