На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
[!] Как относитесь к модерированию на этом форуме? Выскажите свое мнение здесь
Модераторы: Qraizer
Страницы: (2) [1] 2  все  ( Перейти к последнему сообщению )  
> 50 вредных советов для С++ программиста
    Я написал "статью наоборот". Я всегда писал, как сделать C++ код лучше. В этот раз я перешёл на тёмную сторону. Предлагаю вашему вниманию "50 вредных советов для С++ программиста". Будьте аккуратны. Там зло. Если что - я вас предупреждал :).

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

    Приятного чтения!
      Почему советы нумеруются не с 0. Это как-то не по С++. Фу! :D
      Сообщение отредактировано: macomics -
        Цитата macomics @
        Почему советы нумеруются не с 0. Это как-то не по С++.
        Советы ж вредные. Читай название темы. :sarcasm:
          Тогда стоит добавить такой совет. Раз яблоки считаем в штуках с 1, то зачем нам в массивах 0 элемент.
            Хе, CleanX64, дарова!

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

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

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

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

                Оглашай детали :rolleyes:
                  Цитата Majestio @
                  Осмелюсь от себя написать отсебятину, не бегите стирать и развидивать, я не желаю вам зла
                  Спасибо :). Ради спортивной дискуссии:

                  Цитата
                  Ваш лого вызывает отвращение.
                  Нам нравится наш единорог и менять его на что-то мы не планируем :). Впрочем, он стал поприличнее и уже (почти) не блюёт радугой. И вообще он постепенно развивается. Если интересно, то у нас даже есть посвященная ему статья: Неожиданная статья про нашего единорога: кто такой маскот PVS-Studio?
                  Цитата
                  Я видел ваши стартовые ценники - сурово и махрово.
                  PVS-Studio - B2B продукт. С ценами всё хорошо. А для остальных случаев у нас есть несколько вариантов бесплатного лицензирования.
                  Цитата
                  Смотрите ценник - лучше продать 1 млн копий по $10, чем 5000 копий по $2000. Реально - вам это будет проще!
                  Нет. Мы уже это проходили. См. историю про вариант за $250 - Мы закрываем проект CppCat.
                  Цитата
                  Кстати, за коммерческую рекламу у нас на форуме отвечает модератор - Qraizer. Не забываем - URL's платные
                  Пообщаемся.

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

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

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

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

                    Как-то пытался проверять и предотвращать подобные ошибки. Спасибо библиотеке safeint. Но всё равно выходит сурово.
                      Если рассмотреть Intel ассемблер, то в командах индексы это числа со знаком.
                      В 16-битном коде индексы были 16-битными и int тоже был 16-битным. Индекс в виде непосредственного значения в командах тоже представлен как 16-битное число со знаком. Не говоря уже про адресацию, где значение вычисляется segment * 16 + offset
                      ExpandedWrap disabled
                        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 тоже определен в дополнительном коде.
                      ExpandedWrap disabled
                        mov [ebx + esi * 8 - $10000], eax
                        ;           ^----------+^- индекс
                        mov ecx, [-16]
                        ;          ^- индекс

                      В 64-битном коде индексы остаются 32-битными числами потому, что непосредственные значения в командах ограничены 32-битными числами со знаком. int тоже остается 32-битным, хотя виртуальное адресное пространство может адресоваться только 64-битными значениями. Но теперь непосредственные 32-битные значения из команд расширяются со знаком до 64-бит и прибавляются к RIP (указателю команд). Про адресацию вообще хочется промолчать. Канонические адреса - знаковые числа. т.е. в 64-битном режиме у нас адресное пространство находится в пределах $F000000000000000 .. $0FFFFFFFFFFFFFFF (+/- 57-бит)
                      ExpandedWrap disabled
                        mov rax, [index] ; RIP + index - $
                        ;           ^- индекс
                        mov rcx, [rbx + rsi * 8 - $10000]
                        ;                ^----------+^- индекс


                      Хотя возможно я ошибаюсь. Это только мое предположение. Но поведение типа int в C++ совпадает с синтаксисом команд Intel.
                        Индексы знаковые, т.к. адресация может быть и с отрицательными смещениями относительно базы. В отличие от размеров. Потому и есть ptrdiff_t помимо size_t
                          Цитата CleanX64 @
                          Цитата Majestio @
                          Осмелюсь от себя написать отсебятину, не бегите стирать и развидивать, я не желаю вам зла
                          Спасибо :). Ради спортивной дискуссии:

                          Та не вопрос! ;)

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

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

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

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

                          И да, все видят и понимают цель вброса ваших линков на нашем форуме. Но давайте быть честными - отстегните небольшой рекламный бюджет в пользу администрации форума. Контактные лица в прямой досягаемости - модер Qraizer, и админ Vot (а с ним вааще можно замутить круглосуточные банеры вашего программного продукта). Честная реклама - это позитивно, современно и профессионально! :good:
                            И даа, немного есчо ... я вот прямо сейчас пообщялся с британскими учеными, и они мне задали злободневный вопрос:"а почему те креативные парни до сих пор не замутили замануху в виде онлайн-анализатора С++ с ограниченными возможностями, и с годовой подпиской на некоторые расширения (не все)". И ты знаешь, у меня ответа нет! Хотя я себя считаю уверенным пользователем Гугл Транслятора! :victory:
                              Цитата Majestio @
                              Оглашай детали

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

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

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

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

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

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


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0459 ]   [ 16 queries used ]   [ Generated: 28.03.24, 13:16 GMT ]