50 вредных советов для С++ программиста

[CleanX64]

Я написал "статью наоборот". Я всегда писал, как сделать C++ код лучше. В этот раз я перешёл на тёмную сторону. Предлагаю вашему вниманию "50 вредных советов для С++ программиста". Будьте аккуратны. Там зло. Если что - я вас предупреждал .

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

Приятного чтения!

[macomics]

Почему советы нумеруются не с 0. Это как-то не по С++. Фу!

Сообщение отредактировано: macomics - 15.06.22, 18:11

[Qraizer]

Цитата macomics @ 15.06.22, 18:08

Почему советы нумеруются не с 0. Это как-то не по С++.

Советы ж вредные. Читай название темы.

[macomics]

Тогда стоит добавить такой совет. Раз яблоки считаем в штуках с 1, то зачем нам в массивах 0 элемент.

[Majestio]

Хе, CleanX64, дарова!

Я помню тебя, и помню твой "прожект" . Хорошее дело делаете, но совсем не прислушиваетесь к потенциальному потребителю!

Осмелюсь от себя написать отсебятину, не бегите стирать и развидивать, я не желаю вам зла:

• Ваш лого вызывает отвращение. Точно помню, что это "какое-то животное, блюющее радугой". Животное и IT - как-то слабо совместимо, а радуга - символ ЛГБТ еще больше усугубляет. Вам нужен ребрендинг! Просто почитайте историю бренда adidas, они не побоялись, и они до сих пор в тренде;
• Я видел ваши стартовые ценники - сурово и махрово. Но так дела не делаются! Возьмите за бизнесс-модель продукт CCleaner. Там просто адово-адовая туча пользователей за счет "нежадности". Не будьте жадными, отдайте на Free версию 50% способностей вашего продукта. А потом впилите проф и extented пакеты. Просто уверен, после этого к вам потянется покупатель. Как пример, конечно не пионерский, я пакет EssentialPIM купил спустя около 10 лет его нелегального использования, но все же купил! Производитель просто мне вломил качеством, и я сдался. Но сопротивлялся из всех сил;
• Ваш чекер кода вызывает уважение, и это несомненно. Смотрите ценник - лучше продать 1 млн копий по $10, чем 5000 копий по $2000. Реально - вам это будет проще!

Кстати, за коммерческую рекламу у нас на форуме отвечает модератор - Qraizer. Не забываем - URL's платные
Счастья и процветания!

[shm]

2 совета из списка достаточно спорные.

[Majestio]

Цитата shm @ 15.06.22, 19:28

2 совета из списка достаточно спорные.

Оглашай детали

[CleanX64]

Цитата Majestio @ 15.06.22, 18:57

Осмелюсь от себя написать отсебятину, не бегите стирать и развидивать, я не желаю вам зла

Спасибо . Ради спортивной дискуссии:

Цитата

Ваш лого вызывает отвращение.

Нам нравится наш единорог и менять его на что-то мы не планируем . Впрочем, он стал поприличнее и уже (почти) не блюёт радугой. И вообще он постепенно развивается. Если интересно, то у нас даже есть посвященная ему статья: Неожиданная статья про нашего единорога: кто такой маскот PVS-Studio?

Цитата

Я видел ваши стартовые ценники - сурово и махрово.

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

Цитата

Смотрите ценник - лучше продать 1 млн копий по $10, чем 5000 копий по $2000. Реально - вам это будет проще!

Нет. Мы уже это проходили. См. историю про вариант за $250 - Мы закрываем проект CppCat.

Цитата

Кстати, за коммерческую рекламу у нас на форуме отвечает модератор - Qraizer. Не забываем - URL's платные

Пообщаемся.

Ещё раз спасибо за отзыв и интерес к нашему проекту!

[Eric-S]

Касательно совета 8. Мне понятна причина, почему надо использовать memsize типы. Это уже разбиралась раньше во многих статьях.

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

А потом я прочитал рекомендации google по стилю. И внезапно, они на полном серьёзе, рекомендуют использовать int. Именно int.
Ну ладно, наверное проблемы легаси, наплевать и забыть.

Только вот в использовании signed типов, имеется определённая логика.
Проблема вылезает из-за арифметики. unsigned меньше нуля, становится больше нуля.
И вроде бы уже банальное выражение, где collection.size() - sub_length... Может создать ошибку.

Как-то пытался проверять и предотвращать подобные ошибки. Спасибо библиотеке safeint. Но всё равно выходит сурово.

[macomics]

Если рассмотреть Intel ассемблер, то в командах индексы это числа со знаком.
В 16-битном коде индексы были 16-битными и int тоже был 16-битным. Индекс в виде непосредственного значения в командах тоже представлен как 16-битное число со знаком. Не говоря уже про адресацию, где значение вычисляется segment * 16 + offset

mov [bx+$1000], al
;         ^- индекс
mov cx, [bp-$1800]
;             ^- индекс
mov ax, [-$1006]
;           ^- индекс
mov [bx+si-$10], cx
;        ^-+^-- индекс

В 32-битном коде индексы становятся 32-битными числами со знаком и int тоже становится 32-битным. Индексы в виде непосредственных значений в командах тоже представляются уже как 32-битные числа со знаком. Здесь адресация тоже вычисляется как descriptor.base + offset, а descriptor.limit тоже определен в дополнительном коде.

mov [ebx + esi * 8 - $10000], eax
;           ^----------+^- индекс
mov ecx, [-16]
;          ^- индекс

В 64-битном коде индексы остаются 32-битными числами потому, что непосредственные значения в командах ограничены 32-битными числами со знаком. int тоже остается 32-битным, хотя виртуальное адресное пространство может адресоваться только 64-битными значениями. Но теперь непосредственные 32-битные значения из команд расширяются со знаком до 64-бит и прибавляются к RIP (указателю команд). Про адресацию вообще хочется промолчать. Канонические адреса - знаковые числа. т.е. в 64-битном режиме у нас адресное пространство находится в пределах $F000000000000000 .. $0FFFFFFFFFFFFFFF (+/- 57-бит)

mov rax, [index] ; RIP + index - $
;           ^- индекс
mov rcx, [rbx + rsi * 8 - $10000]
;                ^----------+^- индекс

Хотя возможно я ошибаюсь. Это только мое предположение. Но поведение типа int в C++ совпадает с синтаксисом команд Intel.

[Qraizer]

Индексы знаковые, т.к. адресация может быть и с отрицательными смещениями относительно базы. В отличие от размеров. Потому и есть ptrdiff_t помимо size_t

[Majestio]

Цитата CleanX64 @ 15.06.22, 20:34

Цитата Majestio @ 15.06.22, 18:57

Осмелюсь от себя написать отсебятину, не бегите стирать и развидивать, я не желаю вам зла

Спасибо . Ради спортивной дискуссии:

Та не вопрос!

Цитата CleanX64 @ 15.06.22, 20:34

Цитата

Ваш лого вызывает отвращение.

Нам нравится наш единорог и менять его на что-то мы не планируем . Впрочем, он стал поприличнее и уже (почти) не блюёт радугой. И вообще он постепенно развивается.

Не, единорог - норм, хорошая фишка. Толька блевание радугой портит всю репутацию! Я против радуги и ЛГБТ! "Запустите" своего единорога в цифровую вселенную двоичной системы счисления. Нули и единицы - красивше радуги во сто крат, и не такие противные!

Цитата CleanX64 @ 15.06.22, 20:34

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

А вот и нет. Не хорошо у вас с продажами! У того же CCleaner чуть более ТРИЛЛИОНА скачек! Триллиона, Карл!!! Да, это не прямые продажи - но это аудитория с потенциалом покупки. Забудьте про свою уверенность, прислушайтесь!

И да, все видят и понимают цель вброса ваших линков на нашем форуме. Но давайте быть честными - отстегните небольшой рекламный бюджет в пользу администрации форума. Контактные лица в прямой досягаемости - модер Qraizer, и админ Vot (а с ним вааще можно замутить круглосуточные банеры вашего программного продукта). Честная реклама - это позитивно, современно и профессионально!

[Majestio]

И даа, немного есчо ... я вот прямо сейчас пообщялся с британскими учеными, и они мне задали злободневный вопрос:"а почему те креативные парни до сих пор не замутили замануху в виде онлайн-анализатора С++ с ограниченными возможностями, и с годовой подпиской на некоторые расширения (не все)". И ты знаешь, у меня ответа нет! Хотя я себя считаю уверенным пользователем Гугл Транслятора!

[shm]

Цитата Majestio @ 15.06.22, 19:29

Оглашай детали

п.8 По поводу использования int в качестве индекса вопрос спорный и не раз поднимался в сети. Многие опытные С++ программисты как раз таки склонны использовать int для индексации, если размер данных заведомо ограничен. Этому есть определенные доводы, я уже все их не помню, но выглядели они весьма убедительно. Сам обычно использую итераторы, в редких случаях size_t/int.
п.17 тоже спорный. Тут все конечно зависит от продукта, что-то может упасть и перезапуститься без фатальных последствий, что-то нет. Необработанный bad_alloc довольно удобно увидеть в дампе и попытаться раскопать причину утечки. Если bad_alloc пытаться обрабатывать, то эту самую утечку можно просто не увидеть, это будет выглядеть как "отвалившийся" функционал. Опять же, обрабатывать bad_alloc на каждой операции с std::string может привести к чрезмерному усложнению кода, а противоположная ситуация (где-то в одном месте на весь поток) делает бессмысленной эту обработку. Если речь идет о каких-то МК, где падать никак нельзя, то обычно вместо динамического выделению заранее резервируют определенные пространства фиксированного размера. Потому что динамическое выделение может страдать от фрагментации.

Сообщение отредактировано: shm - 16.06.22, 11:10

[Eric-S]

Цитата shm @ 16.06.22, 11:06

Цитата Majestio @ 15.06.22, 19:29

Оглашай детали

п.8 По поводу использования int в качестве индекса вопрос спорный и не раз поднимался в сети. Многие опытные С++ программисты как раз таки склонны использовать int для индексации, если размер данных заведомо ограничен. Этому есть определенные доводы, я уже все их не помню, но выглядели они весьма убедительно. Сам обычно использую итераторы, в редких случаях size_t/int.

Ага. Доводы тоже читал за и контра. Вопрос и ответ, действительно, неоднозначный.

И да, обычно использую итераторы или size_t.

Предпочтение size_t для стандартных контейнеров в том, что функция класса size(), возвращает именно size_t. А если смешивать, signed и unsigned, то компилятор ворчит.

А как-то, для самодельного микро-контейнера закольцованного буфера, где число элементов не могло превысить 256, размер же объекта имел значение, я вообще использовал uint8_t.