| Версия для печати
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум на Исходниках.RU > C/C++: Прочее > 50 вредных советов для С++ программиста |
| Автор: CleanX64 15.06.22, 17:44 |
Я написал "статью наоборот". Я всегда писал, как сделать C++ код лучше. В этот раз я перешёл на тёмную сторону. Предлагаю вашему вниманию "50 вредных советов для С++ программиста". Будьте аккуратны. Там зло. Если что - я вас предупреждал  . К сожалению, некоторые программисты не согласятся, что все советы в той или иной степени вредные. Поэтому я заранее написал пояснения к наиболее неоднозначным пунктам. Думаю, у каждого найдётся коллега, кому будет полезно всё это почитать .Приятного чтения! |
| Автор: macomics 15.06.22, 18:08 |
Почему советы нумеруются не с 0. Это как-то не по С++. Фу!  |
| Автор: Qraizer 15.06.22, 18:21 |
Советы ж вредные. Читай название темы.  |
| Автор: macomics 15.06.22, 18:29 |
| Тогда стоит добавить такой совет. Раз яблоки считаем в штуках с 1, то зачем нам в массивах 0 элемент. |
| Автор: Majestio 15.06.22, 18:57 |
| Хе, CleanX64, дарова! Я помню тебя, и помню твой "прожект"  . Хорошее дело делаете, но совсем не прислушиваетесь к потенциальному потребителю!Осмелюсь от себя написать отсебятину, не бегите стирать и развидивать, я не желаю вам зла: Кстати, за коммерческую рекламу у нас на форуме отвечает модератор - Qraizer. Не забываем - URL's платные Счастья и процветания!  |
| Автор: shm 15.06.22, 19:28 |
| 2 совета из списка достаточно спорные. |
| Автор: Majestio 15.06.22, 19:29 |
| Оглашай детали  |
| Автор: CleanX64 15.06.22, 20:34 |
| Цитата Majestio @ Спасибо Осмелюсь от себя написать отсебятину, не бегите стирать и развидивать, я не желаю вам зла . Ради спортивной дискуссии:Цитата Нам нравится наш единорог и менять его на что-то мы не планируем Ваш лого вызывает отвращение. . Впрочем, он стал поприличнее и уже (почти) не блюёт радугой. И вообще он постепенно развивается. Если интересно, то у нас даже есть посвященная ему статья: Неожиданная статья про нашего единорога: кто такой маскот PVS-Studio?Цитата PVS-Studio - B2B продукт. С ценами всё хорошо. А для остальных случаев у нас есть несколько вариантов бесплатного лицензирования.Я видел ваши стартовые ценники - сурово и махрово. Цитата Нет. Мы уже это проходили. См. историю про вариант за $250 - Мы закрываем проект CppCat.Смотрите ценник - лучше продать 1 млн копий по $10, чем 5000 копий по $2000. Реально - вам это будет проще! Цитата Пообщаемся.Кстати, за коммерческую рекламу у нас на форуме отвечает модератор - Qraizer. Не забываем - URL's платные Ещё раз спасибо за отзыв и интерес к нашему проекту! |
| Автор: Eric-S 15.06.22, 23:01 |
| Касательно совета 8. Мне понятна причина, почему надо использовать memsize типы. Это уже разбиралась раньше во многих статьях. Но меня одолевает чуть иной вопрос. Каким, в плане знаковости, должен быть тип индекса? По логике, unsigned это самое то. И соответственно для циклов size_t будет корректным. А потом я прочитал рекомендации google по стилю. И внезапно, они на полном серьёзе, рекомендуют использовать int. Именно int. Ну ладно, наверное проблемы легаси, наплевать и забыть. Только вот в использовании signed типов, имеется определённая логика. Проблема вылезает из-за арифметики. unsigned меньше нуля, становится больше нуля. И вроде бы уже банальное выражение, где collection.size() - sub_length... Может создать ошибку. Как-то пытался проверять и предотвращать подобные ошибки. Спасибо библиотеке safeint. Но всё равно выходит сурово. |
| Автор: macomics 16.06.22, 00:47 |
| Если рассмотреть Intel ассемблер, то в командах индексы это числа со знаком. В 16-битном коде индексы были 16-битными и int тоже был 16-битным. Индекс в виде непосредственного значения в командах тоже представлен как 16-битное число со знаком. Не говоря уже про адресацию, где значение вычисляется segment * 16 + offset <{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}> 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 тоже определен в дополнительном коде. <{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}> mov [ebx + esi * 8 - $10000], eax ; ^----------+^- индекс mov ecx, [-16] ; ^- индекс В 64-битном коде индексы остаются 32-битными числами потому, что непосредственные значения в командах ограничены 32-битными числами со знаком. int тоже остается 32-битным, хотя виртуальное адресное пространство может адресоваться только 64-битными значениями. Но теперь непосредственные 32-битные значения из команд расширяются со знаком до 64-бит и прибавляются к RIP (указателю команд). Про адресацию вообще хочется промолчать. Канонические адреса - знаковые числа. т.е. в 64-битном режиме у нас адресное пространство находится в пределах $F000000000000000 .. $0FFFFFFFFFFFFFFF (+/- 57-бит) <{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}> mov rax, [index] ; RIP + index - $ ; ^- индекс mov rcx, [rbx + rsi * 8 - $10000] ; ^----------+^- индекс Хотя возможно я ошибаюсь. Это только мое предположение. Но поведение типа int в C++ совпадает с синтаксисом команд Intel. |
| Автор: Qraizer 16.06.22, 01:13 |
| Индексы знаковые, т.к. адресация может быть и с отрицательными смещениями относительно базы. В отличие от размеров. Потому и есть ptrdiff_t помимо size_t |
| Автор: Majestio 16.06.22, 05:17 |
| Цитата CleanX64 @ Цитата Majestio @ Спасибо Осмелюсь от себя написать отсебятину, не бегите стирать и развидивать, я не желаю вам зла . Ради спортивной дискуссии:Та не вопрос!  Цитата CleanX64 @ Цитата Нам нравится наш единорог и менять его на что-то мы не планируем Ваш лого вызывает отвращение. . Впрочем, он стал поприличнее и уже (почти) не блюёт радугой. И вообще он постепенно развивается.Не, единорог - норм, хорошая фишка. Толька блевание радугой портит всю репутацию! Я против радуги и ЛГБТ! "Запустите" своего единорога в цифровую вселенную двоичной системы счисления. Нули и единицы - красивше радуги во сто крат, и не такие противные! Цитата CleanX64 @ С ценами всё хорошо. А для остальных случаев у нас есть несколько вариантов бесплатного лицензирования. А вот и нет. Не хорошо у вас с продажами! У того же CCleaner чуть более ТРИЛЛИОНА скачек! Триллиона, Карл!!! Да, это не прямые продажи - но это аудитория с потенциалом покупки. Забудьте про свою уверенность, прислушайтесь! И да, все видят и понимают цель вброса ваших линков на нашем форуме. Но давайте быть честными - отстегните небольшой рекламный бюджет в пользу администрации форума. Контактные лица в прямой досягаемости - модер Qraizer, и админ Vot (а с ним вааще можно замутить круглосуточные банеры вашего программного продукта). Честная реклама - это позитивно, современно и профессионально! |
| Автор: Majestio 16.06.22, 05:37 |
И даа, немного есчо ... я вот прямо сейчас пообщялся с британскими учеными, и они мне задали злободневный вопрос:"а почему те креативные парни до сих пор не замутили замануху в виде онлайн-анализатора С++ с ограниченными возможностями, и с годовой подпиской на некоторые расширения (не все)". И ты знаешь, у меня ответа нет! Хотя я себя считаю уверенным пользователем Гугл Транслятора!  |
| Автор: shm 16.06.22, 11:06 |
| п.8 По поводу использования int в качестве индекса вопрос спорный и не раз поднимался в сети. Многие опытные С++ программисты как раз таки склонны использовать int для индексации, если размер данных заведомо ограничен. Этому есть определенные доводы, я уже все их не помню, но выглядели они весьма убедительно. Сам обычно использую итераторы, в редких случаях size_t/int. п.17 тоже спорный. Тут все конечно зависит от продукта, что-то может упасть и перезапуститься без фатальных последствий, что-то нет. Необработанный bad_alloc довольно удобно увидеть в дампе и попытаться раскопать причину утечки. Если bad_alloc пытаться обрабатывать, то эту самую утечку можно просто не увидеть, это будет выглядеть как "отвалившийся" функционал. Опять же, обрабатывать bad_alloc на каждой операции с std::string может привести к чрезмерному усложнению кода, а противоположная ситуация (где-то в одном месте на весь поток) делает бессмысленной эту обработку. Если речь идет о каких-то МК, где падать никак нельзя, то обычно вместо динамического выделению заранее резервируют определенные пространства фиксированного размера. Потому что динамическое выделение может страдать от фрагментации. |
| Автор: Eric-S 16.06.22, 12:26 |
| Цитата shm @ п.8 По поводу использования int в качестве индекса вопрос спорный и не раз поднимался в сети. Многие опытные С++ программисты как раз таки склонны использовать int для индексации, если размер данных заведомо ограничен. Этому есть определенные доводы, я уже все их не помню, но выглядели они весьма убедительно. Сам обычно использую итераторы, в редких случаях size_t/int. Ага. Доводы тоже читал за и контра. Вопрос и ответ, действительно, неоднозначный. И да, обычно использую итераторы или size_t. Предпочтение size_t для стандартных контейнеров в том, что функция класса size(), возвращает именно size_t. А если смешивать, signed и unsigned, то компилятор ворчит. А как-то, для самодельного микро-контейнера закольцованного буфера, где число элементов не могло превысить 256, размер же объекта имел значение, я вообще использовал uint8_t. |
| Автор: Qraizer 16.06.22, 12:45 |
| Почему-то не увидел «Вам надоело постоянно писать std:: в своих заголовках? Смело вставляйте using namespace std прям в начало, Вам обязательно скажут "спасибо" все пользователи, т.к. их тоже задолбало вставлять в свои программы и то, и другое.» Ну и перенумеровать соответственно, а то как же без off-by-one error-то... |