1. C++ / Говнокод #3388

    +1001

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    struct Dir {
        Dir(const char* name) {
            d = opendir("/var/log");
        }
        ~Dir();
        const char* next();
        bool operator== (DIR* other);
    private:
        DIR* d;
    };
    ...
    Dir var_log("/var/log");

    Запостил: evlad, 03 Июня 2010

    Комментарии (39) RSS

    • Похоже на какую-то заготовку.
      Ответить
      • не обязательно.

        у нас в софтине в одном месте одна константа всегда была 0. потом ей дали другое значение - сразу в стольких местах повылазило что народ на протяжении многих лет вместо этой константы просто 0 писал. и более того нашлось место где код ожидал что константа будет 0 и использовал ее не по назначению вместо 0.

        это часто происходит когда пишется навороченно абстрактный код, который в жизни используется только по одному конкретному назначению. почему я и пытаюсь народ учить сначала писать конкретный код и потом из него по мере необходимости делать абстрактный, переиспользуемый, а не наоборот. ан нет, крутых книжек поначитаются и начинают городить огороды.
        Ответить
        • Ну вот сначала и писали конкретный. Под /var/log, а потом забыли вынести это как параметр.
          Ответить
    • Вызов opendir() в конструкторе - это сильно.
      Ответить
      • В чем сила, брат © ?
        Ответить
        • В ньютонах.
          Ответить
        • Хотя да, погорячился, так впринципе тоже покатит )
          Просто я бы делал opendir() не в конструкторе, а в другом методе, чтобы можно было заранее обработать ошибку на этом этапе.
          Ответить
          • Для обработки ошибок в конструкторах собственно собственно и придуманы исключения. Ну или можно сделать метод is_ok().
            Ответить
            • Исключение - это не всегда ошибка. И придуманы они (исключения) вовсе не для ошибок в конструкторах.
              Ответить
              • >>Исключение - это не всегда ошибка. И придуманы они (исключения) вовсе не для ошибок в конструкторах

                ололо! а для чего ж они?
                Надеюсь, Вы не из тех макак, которые всё API строят на эксепшенах, называя это "архитектурой сооьшений"?
                Ответить
                • Как вариант - быстрый способ выйти из вложенных циклов.
                  Почитайте Страуструпа. Раздел 14.5.
                  P.S. Надеюсь, Вы тоже не обезьяна. А то с приматами общаться не получается.
                  Ответить
                  • Правильный способ выхода из вложенных циклов - return. На худой конец гото. Но в реальности нет причин не выносить группы вложеных циклов в функцию.
                    Ответить
                    • нормальный выход -- условие.

                      while (someCondition) {
                      ...

                      if (poraVihodit) someCondition = false
                      Ответить
                      • goto в данном случае лучше, проще и нагляднее.
                        Ответить
                        • Знаете, я с вами даже соглашусь, за что буду обосран толпой анонимусов. Вероятно это связано с тем, что многие анонимусы меньше практиковали с ассемблером, где кроме джампов ничего собственно и нет :). Сейчас попробую обосновать позицию с goto для случая вложенных циклов, когда требуется выйти из циклов немедленно:
                          1.) Если делать с дополнительной переменной в условии надо будет добавлять эту переменную во все уловиях для уровней вложения (кроме разве что последнего), что вообще говоря неудобно
                          2.) Лично мне goto будет действительно удобнее воспринимать во многих ситуациях, чем с дополнительной переменной в условиях.
                          3.) Хоть это и копейки, но компьютеру надо будет выполнять меньше операций на полный цикл.
                          Т.е. это оптимальнее, нагляднее и быстрее пишется для рассмотренного случая, чем добавление переменной в условия. Хотя справедливости ради стоит заметить, что, как уже сказали выше, эту же проблему можно решить вынеся эти циклы в отдельную функцию, на что некоторые с дуру могут возразить, что это спровоцирует дополнительные вызовы функций, что в свою очередь можно решить добавив inline по надобности.. однако это решение иногда делает код менее наглядным, либо требует передачи тонны переменных туда и обратно, что тоже иногда очень неудобно.

                          Однако, IMHO, это вопрос строго стиля программирования. И спорить на эту тему абсолютно бесполезно. А единственные две объективные величины для хуже/лучше, которые мы можем замерить это:
                          1.) производительность;
                          2.) работоспособность.

                          Конкретно в данном случае меняется только первое. Соотвественно, единственное, что можно делать при стремлении к идеалу, в данной ситуации надо, IMHO, просто проверять что выполняется быстрее. Но, как известно, если слишком сильно загоняться на оптимальности, код становится иногда слишком сложночитаемым... я, конечно, извиняюсь, что озвучиваю столь очевидные вещи, однако похоже, тут некоторые анонимусы любят принимать решения строго на религиозных соображениях.
                          Ответить
                          • тибя че графоман покусал?
                            Ответить
                            • Читать лень? :)
                              Ответить
                              • пиздец партянки
                                ты код также пишеш? китаец штоле?
                                Ответить
                                • Странные вы аналогии проводите. Однако, если вы так любите краткие ответы - нет.
                                  Ответить
                                • Код — нет.
                                  А комментарии — да!:)
                                  Ответить
                          • Спасибо!

                            Насчет догматов — они хороши при первоначальном ознакомлении с предметом, для выработки ориентиров. Потом, когда научаешься отличать «добро» от «зла», приходит осознание, что мир серый, и что из любого правила будут исключения.
                            Это нормально, это вроде как в БИ концепция сю-ха-ри. Ненормально, когда индивидуум застревает на этапе «сю».
                            Ответить
                          • Вот тут http://www.linux.org.ru/forum/development/3520569 обсуждение этого вопроса с бенчмарками.
                            Ответить
                            • Прочитав первое сообщение мне показалось, что там другая тема обсуждается, хоть и похожая. Или надо дальше читать?
                              Ответить
                              • Всё, нашёл, :). Спасибо за ссылку.
                                Выкладываю результат по ссылке:
                                Ниже приведён код, которых я сегодня гонял в профайлере и так.
                                По данным cacherind места распределились следующим образом:
                                loops_goto      74965434
                                loops_counters  74965463
                                loops_return    74965637
                                loops_throw     75066212
                                loops_flag      75310638
                                Ответить
                                • Я думаю, очевидно, что выбирать надо из первых трёх. А последний со всех сторон плохой вариант: и код удлиняет и работает ощутимо медленнее.
                                  Ответить
                  • И между прочим, формально человеки - тоже приматы.
                    Ответить
            • м?
              try
              {
              Dir d("/path/to/gigantic/hui");
              }
              catch(super_exc e)
              {

              }
              так чтоли?

              А если такая область видимости не подходит?
              Ответить
              • Как она может не подойти? У тебя либо есть директория и путь к ней, либо тебе нечего делать. Ну и можно положиться на вышестоящий throw, если вероятность облома мала (например, диру выбрал юзер штатной выбиралкой директорий)
                Ответить
                • допустим, мне нужен глобальный объект.
                  Ответить
      • А что не так?
        Ответить
    • А в структуре можно разве обьялять конструктор/деструктор?)) Это что попытка связный список сделать??? Притом коструктор сдесь веселый)))) Вобщем бредатина)))
      Ответить
      • Разумеется можно. Ты бы книжку по языку почитал бы. Хоть одну.
        Ответить
        • Тогда нахрена нужны объекты? о_О
          Ответить
          • Не путайте объекты и классы (class).
            Объект - это по сути любой экземпляр класса, структуры или встроенного типа.
            В С++ ключевые слова class и struct взаимозаменяемы. Разница только в правах доступа по-умолчанию к членам.
            В структурах - public, в классах - private.
            Ответить
            • Окей, окей, формально был некорректен.
              Тогда, спрашивается, нахрена нам нужны классы вообще? Если теперь модно у структур делать методы. Не совсем уверен насчёт наследования, оно там есть? (Искать лень, если честно, да и не настолько я цппбой).
              Второй вопрос. Если у классов - объекты, что тогда у структур? Структуры?
              Ответить
              • >Не совсем уверен насчёт наследования, оно там есть?
                Есть.
                В С++ структуры почти не отличаются от классов.
                Отличаются лишь тем, что в классе всё поумолчанию имеет private модификатор, а структуре public.
                Ответить
          • >>Тогда нахрена нужны объекты?

            Ух ты, какие серьезные вопросы на говнокоде обсуждаются
            Ответить

    Добавить комментарий