Кресты / Говнокод #10587 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
BOOL CIniFile::LoadIniFile()
{
  CString csBuff;
  CFile oIniFile;
  if (oIniFile.Open(csIniFileName, CFile::modeRead))
  {
    ULONGLONG lenReal = oIniFile.GetLength();
    DWORD dwLen = (DWORD) lenReal;
    if (lenReal > UINT_MAX)
    {
      dwLen = UINT_MAX;
      TRACE("ERROR: CIniFile::LoadIniFile();  CFIle::GetLength() > UINT_MAX\n;");
      ASSERT(0);
    }
    if (!dwLen)
      return FALSE;
    boost::scoped_array <char> cBuffer(new char[dwLen]);
    oIniFile.Read(cBuffer.get(), dwLen);
    LoadIniFromBuffer(cBuffer.get(), dwLen);
    oIniFile.Close();
    if (GetCountRecords())
      return TRUE;
  }
  return FALSE;
}

boost::scoped_array... nuff said =(

Запостил: kovyl2404 kovyl2404, (Updated )

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

  • ava vistefan # Ссылка на оригинал 0

    Программист "без царя в голове", о чём можно судить даже по бессистемным именам переменных:
    > lenReal
    > dwLen
    "len" идёт то как префикс, то как постфикс.
    Хотя, может быть это эффект того, что над кодом работал не один человек...
    Ответить

    • ava kovyl2404 # Ссылка на оригинал 0 ⇈

      Над проектом работало три-четыре человека. Как я понял больные на голову. Что уж говорить, я месяц занимаюсь этим проектом и до сих пор не смог его даже собрать 0_о
      Ответить

    • ava kovyl2404 # Ссылка на оригинал 0 ⇈

      Уж с ним-то все отлично. Вон defecate-plusplus парой коментов выше разъяснил мое недовольство =)
      Ответить

      • ava Kirinyale # Ссылка на оригинал 0 ⇈

        Ну буст - штука необъятная, весь сходу не заучишь. Мне как-то тоже не всегда приходит в голову искать в нём то, что и так несложно написать. Другое дело - после того как разок носом ткнут (или сам ткнусь случайно). С аргументацией, а точно ли оно мне надо.
        Ответить

        • ava kovyl2404 # Ссылка на оригинал 0 ⇈

          Да понятно, что буст - огроменная помойка. Но раз уж решили ее притянуть в проект, то лучше ж все-таки убедиться (читай "погуглить"), а нет ли в ней того, что собираетесь писать. Кстати, во всем проекте буст используется лишь с такой оригинальной целью, которую я продемонстрировал.
          Ответить

    • ava HaskellGovno # Ссылка на оригинал 0 ⇈

      >Что не так с boost::scoped_array?
      Не нужен. Use std::vector, Luke! Познай силу тёмной стороны.
      Ответить

      • ava Kirinyale # Ссылка на оригинал 0 ⇈

        Я лично предпочитаю называть вещи своими именами. Если мне нужен простой массив фиксированного (пусть и неизвестного на этапе компиляции) размера, который требуется вовремя удалить, то я его и создаю. Перед векторами изначально ставятся несколько другие (хоть и совместимые) цели. И sizeof у них побольше будет (в той реализации STL, которая в VS2008 - в пять раз, по крайней мере для 32-битной платформы). Мелочь? Может быть, но зачем всё это нужно при наличии простой и специализированной альтернативы?

        Конечно, об извратах типа подключения к проекту целого буста ради одного scoped_array я сейчас не говорю. Но уж если подключать ради чего-то другого, то грех не пользоваться.
        Ответить

        • ava bormand # Ссылка на оригинал 0 ⇈

          Вы так говорите, как-будто буст это что-то огромное (типа дебажного QtGui) и линкуемое в проект целиком.
          Ответить

          • ava Kirinyale # Ссылка на оригинал 0 ⇈

            Хрен с ней с линковкой - я уже задолбался его при каждом удобном случае (вроде обновления или старта нового проекта) копировать, забирать из сорс-контрола, заливать обратно, запаковывать/распаковывать и т.п.. Десятки тыщ мелких файлов жрут время не хуже длинной линковки.
            Ответить

            • ava defecate-plusplus # Ссылка на оригинал 0 ⇈

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

              • ava Kirinyale # Ссылка на оригинал 0 ⇈

                Ну вот так уж у нас принято - сторонние либы (их много), которые используются, лежат рядом с проектом. Чтоб не искать потом нужные версии (даже буст иногда грешит breaking change'ами) по всем интернетам. Кстати да, некоторые заброшенные извращения вроде libtga и редактировать иногда приходится.

                Переустановка винды здесь ни при чём, просто некоторые особенности некоторых сорс-контролов + время от времени необходимость работать из разных мест (из дома, например).

                Буст, впрочем, давно руки тянутся обрезать до минимально необходимой части, благо средства есть. Рано или поздно дотянутся.
                Ответить

                • ava defecate-plusplus # Ссылка на оригинал 0 ⇈

                  это у вас плохо принято
                  когда буст используется в 100% проектов, его не нужно держать рядом с проектом
                  вы же не держите рядом с проектом в сурс-контроле VC/include, правда?
                  а то ведь тоже может так случиться, что дома стоит другая версия студии 😉

                  насчет breaking changes - я на работе его пользую где-то с версии 1.37, да, бывали случаи, но очень не критичные (один раз хедер надо иначе было включить, один раз дописать #define перед включением, один программист полюбил писать boost::system::system_category вместо get_system_category() - и спасибо что в какой то версии это выпилили наконец, ошибка ведь) - случаев очень немного было за 4 года, это не создает непреодолимых проблем

                  и на практике регулярный переход с 1.37 до 1.49 (иногда, быть может, с пропуском через 1-2) за эти годы ни разу не сломал ни один проект, ни один важный проект, во время их работы в поле
                  тестирование то понятное дело без нареканий

                  поэтому держать рядом с каждым проектом зоопарк всех версий буста - это всё от лени "да он тут чото ругается теперь, нунах" и страха "а ну как всё сломается, а я крайний"
                  не сломается
                  Ответить

                  • ava Kirinyale # Ссылка на оригинал 0 ⇈

                    > это у вас плохо принято

                    Нас это пока устраивает и регулярно себя оправдывает. Другая версия студии - плохой пример. Последнее, что помню из засад при обновлении буста - новая версия filesystem, замена вызовов path::string() на path::generic_string() по всему коду и ещё несколько прелестей, которые уже успел забыть. Хотя от этой конкретной либы нам вообще давно пора избавиться (пользовались только ради удобной работы с путями, а либа упорно затачивается на совсем другое).

                    Ну и вообще-то мы не "зоопарк всех версий" держим, а одну конкретную, с которой компилировали. Когда требуется выдать компилируемый код наружу (для портирования, или просто издателю для порядка), это делается простым копированием "как есть" (с обрезанием разве что объектных файлов или ещё чего-нибудь явно ненужного) и упаковкой. Когда нужно посадить на проект нового программиста - он просто забирает всё из перфорса и радуется жизни.

                    Может быть, в каких-то конкретных ситуациях это и "не нужно", но в нашей это работает и нам удобно. Практическую пользу от того, чтобы делать именно так, я вижу. От того, чтобы так не делать - разве что экономия места на серверах (не моя проблема, если честно).
                    Ответить

                    • ava defecate-plusplus # Ссылка на оригинал 0 ⇈

                      > filesystem
                      >> один раз дописать #define перед включением
                      #define BOOST_FILESYSTEM_VERSION 2
#include <boost/filesystem.hpp>
                      fixed
                      Ответить

                      • ava Kirinyale # Ссылка на оригинал 0 ⇈

                        Version 2 is deprecated, and will not be included in Boost releases 1.48 and later.

                        (c)

                        Между тем, уже 1.49. Честно говоря, не проверял - сдержали слово?
                        Ответить

                        • ava defecate-plusplus # Ссылка на оригинал 0 ⇈

                          ага, наверное поэтому оно у меня и в 1.49 работает без проблем

                          она станет deprecated только когда С++11 с копипащеной реализацией filesystem v2 предложит std::filesystem

                          в общем эту проблему в 1.46 или когда там появился v3 я решил именно так и это решение до сих пор отлично работает
                          что будет в 1.50 - не знаю, думаю, останется по-старому
                          Ответить

                          • ava Kirinyale # Ссылка на оригинал 0 ⇈

                            Ну я бы не стал на это расчитывать. Предпочитаю подстраховаться.

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

                            • ava defecate-plusplus # Ссылка на оригинал 0 ⇈

                              ну сломают окончательно - придется решать, и именно переходом на v3 везде, а не добавлением устаревшего буста к проектам
                              в filesystem не только склеивание путей, там еще и итерирование по директории, копирование и удаление файлов, размер файлов
                              и когда всё это надо делать кроссплатформенно, свой велосипед оказывается в проигрышном положении
                              Ответить

                              • ava Kirinyale # Ссылка на оригинал 0 ⇈

                                Для кроссплатформенной работы непосредственно с файлами мы используем PhysicsFS. "Родная" файловая система при этом нас вообще не волнует, т.к. в релизе все ресурсы идут упакованными в архив. Единственное, что требует-таки работы с родной фс - это сейвы, но их (выбор места и непосредственно запись в файл) как раз можно оставить платформенно-зависимым кусочком.
                                Ответить

                    • ava defecate-plusplus # Ссылка на оригинал 0 ⇈

                      > Ну и вообще-то мы не "зоопарк всех версий" держим, а одну конкретную, с которой компилировали.
                      именно про это я и говорю, если у вас один проект, использующий буст, то разницы, конечно, никакой
                      а когда ежеквартально выпуск очередных версий 4-5 проектов (продолжающихся несколько лет), и для каждого из них клеить именно ту версию буста, с которой он зарождался (особенно если проекту года 3 уже) - вот как раз прямой путь к зоопарку
                      особенно если эти проекты начинают в определенный момент шарить общие dll между собой, чтобы не дублировать некую функциональность
                      Ответить

                      • ava Kirinyale # Ссылка на оригинал 0 ⇈

                        Мы игры делаем. Не будут они между собой ничего шарить. Только "движковую" часть в статической библиотеке, которая постоянно развивается параллельно с разработкой каждой следующей игрушки.

                        Двух одновременно на одном фреймворке обычно не делаем. Точнее, попытались как-то раз, но закончилось это заморозкой одного из проектов, т.к. из-за распыления команды страдали оба (с зависимостями это никак не связано). Вот сейчас один выпустили, второй размораживаем, так что опять всё вполне самостоятельно и ничего не шарится.
                        Ответить

                  • ava Kirinyale # Ссылка на оригинал 0 ⇈

                    Кстати, ещё пример - как-то раз после обновления FreeType у меня одни и те же тексты одними и теми же шрифтами стали отрисовываться по-другому. Настолько по-другому, что это заметно невооружённым глазом и проявляется, насколько помню, даже в высоте символов.

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

                • ava HaskellGovno # Ссылка на оригинал 0 ⇈

                  >Ну вот так уж у нас принято - сторонние либы (их много), которые используются, лежат рядом с проектом.
                  Гугли возможность "внешние зависимости" своей системы контроля версий.
                  Ответить

            • ava bormand # Ссылка на оригинал 0 ⇈

              А если бы вы разрабатывали проект на Qt, то вы бы тоже всю библиотеку копировали в сурсконтрол?

              Имхо 3rd'party либы должны лежать отдельно от проекта (если вы их конечно не допиливаете).
              Ответить

              • ava Kirinyale # Ссылка на оригинал 0 ⇈

                Qt не Qt, а wxWidgets там уже валяется (для какого-то редактора кем-то использовался). И даже DirectX SDK "правильной" версии.
                Ответить

  • ava LXxhELT # Ссылка на оригинал 0

    "А стоило бы. В конце концов, это и жизнью-то назвать сложно. Скорее жалкое существование".
    Ответить

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

Переведи на "PHP", guest!

    А не использовать ли нам bbcode?

    ↑
    8
    ↓