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

    +60.6

    1. 1
    2. 2
    3. 3
    static char *szClassName = new char[14];
    static char *szCurrentDirectory = new char[MAX_BUFFER];
    static char *szNewFolder = new char[MAX_BUFFER];

    глобальные указатели рулят, delete нигде не вызывается

    Запостил: shomeser, 20 Сентября 2009

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

    • Память и на стеке можно было выделить. Если MAX_BUFFER не очень большой, конечно.
      Ответить
    • >delete нигде не вызывается
      А зачем для указателей, которые храняться в static, вызывать delete?
      Ответить
      • память выделена оператором new, значит надо delete
        если бы было что-то вроде static char * s = "hello";
        тогда ничего не надо
        Ответить
      • Нужен. Иначе на некоторых платформах и реализациях не будет освобождена память при выходе из программы. В том числе не вызовуться деструкторы.
        Ответить
        • Что же это за платформы такие? Не знаю ни одной, в которой бы не освобождалась память процесса при завершении.
          Ответить
          • Я ошибся. Под платформами я имел ввиду ОС. Насколько я помню в Win3.1, а то и Win95 в некоторых С++ использовался LocalAlloc или GlobalAlloc для выделения памяти. В результате, при выходе из программы, если память не была освобожденна - она безвозвратно терялась для всей ОС.
            Ответить
    • Что static, что не static - все равно. Обычная ошибка джуниора, ничего интересного.
      Ответить
    • Интересно, кому выделение памяти могло пригодиться? Тут можно было обойтись статическим выделением.
      Ответить
    • та вы гоните
      1. память при завершении процесса по-любому освобождается потому как освобождается вся куча стандартным кодом который добавляется компилятором в исполняемый модуль
      2. человек выделяет массивы из стандартных типов, о каких деструкторах идет речь? или для каждого char в массиве нужен деструктор?
      3. Если бы эти массивы были выделены статически то это бы увеличело размер исполняемого модуля на величину выделенного буфера. Например если человек хочет 1 мегабайт буфера (#define MAX_BUFFER 1024) и он пишет static char buffer[MAX_BUFFER]; то считайте что ваш бинарь на метр толще после компиляции, а если делать как этот чел то результат тот же только бинарь на метр худее получается.
      Ответить
      • прогнал, нужно #define MAX_BUFFER 1024*1024 чтобы метр получить
        Ответить
        • Ага. Под szCurrentDirectory нужен метр памяти... :D
          Ответить
          • а вдруг кто-то назовет директорию метровым именем?
            Ответить
            • Такое длинное имя пути не поддерживаеться ОС WinDOS. Длинна имени 255 символов на имя и 255 символов на расширение файла. Да на путь 255 символов.
              Открываем windows.h и видим: #define MAXPATH 256
              Ответить
              • брешешь как сивый мерин. Путь + имя файла + расширение не может быть больше 255 символов. Но это ограничение API а не ntfs. ntfs позволяет хранить файлы с любой длинной пути и именем файла в 255 символов. Для этого правда придется путь подмапливать чтобы API смогло до него добраться.
                Ответить
                • Будто бы ты не через API к файлам обращаешься. Раз АПИ не может, стало быть и не нужен более длинный буфер для пути.
                  >Для этого правда придется путь подмапливать чтобы API смогло до него добраться.
                  Будто бы ты это делаешь в каждой своей программе, что-бы можно было использовать более длинный путь? Это делают лишь в редкостных утилитах, которые в обыденной жизни не используют, раз Explorer.exe не дружит с длинными путями.
                  Ответить
              • цитата из МСДН, CreateFile

                In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend "\\?\" to the path.
                Ответить
                • И часто ты дописываешь к путям "\\?\" при вызове АПИ <(^_^)?
                  Ответить
                  • Нет, так как редко пользуюсь абсолютными путями (у меня ресурсы в паках, пути к пакам относительные и редко превышают 32 символа)...
                    Функции которые возвращают (юникодные версии) путь (к моим документам и тп папкам) сами его дописывают если путь очень длинный (сам не сталкивался но видел в логах)...
                    Ответить
                    • Ну значит не имеет смысла использовать пути, длиннее 32 байт и можно выделять статически. :)
                      Ответить
      • >1. память при завершении процесса по-любому освобождается потому как освобождается вся куча стандартным кодом который добавляется компилятором в исполняемый модуль
        Ну это как программу завершить... Да и как уже было сказано выше - не все реализации С++ одинаково полезны. В некоторых старых не освобождает память, если не чистить.
        >2.человек выделяет массивы из стандартных типов, о каких деструкторах идет речь? или для каждого char в массиве нужен деструктор?
        С таким же успехом могла выделиться память под обьект. Применим new, а потом не чистим и деструктор не вызываеться.
        Ответить
        • Я почему-то уверен, что говнокодер сего говноккода и обьекты бы delete'тить не стал бы. Нах%& ему этот деструктор сдался... Ну не вызовиться... И что? :D
          Ответить
        • с таким же успехом автор мог бы быть голубым
          Ответить
          • имел в виду кодера говнокода а не автора говнопоста
            Ответить
        • >С таким же успехом могла выделиться память под обьект. Применим new, а потом не чистим и деструктор не вызываеться.
          Мне что-то думаеться, что говнокодер этого говнокода как для строк static char *szClassName = new char[14]; не вызывал delete, так и для обьектов...

          Не удивлюсь, если когда нибудь char *, по мере развития проекта, заменят на CString*, то вызываться delete не будет, естественно деструктор тоже не вызоветься.

          Вообще не вызванный деструктор для строк не так важен, но для некоторых критических обьектов это может быть фатально... :(
          Ответить
          • :))) а чего, самый простой garbage collector: просто не вызывай delete и все. Раз в 20 минут перезапускай exeшник автоматически )))
            Ответить
      • А тебе что? Жалко метра, да? Какие сейчас жёсткие диски обьёмом? Пару терабайт, а дальше больше...

        Да сейчас ещё и упаковщики exe'шников хорошие есть. Этот метр, заполненый нулями, упакуеться такой тулзой в пару байт. :)
        Ответить
        • да ты гонишь, меня лично жаба давит как программиста оставить в бинаре метр нулей
          например если сам бинарь весит всего 100 кило прибавлять к нему тонну веса как-то не серьезно
          Ответить
          • массив нулей попадет в секцию неинициализированных данных... то есть в экзешнике просто укажется размер этой секции которая при старте забьется нулями...
            Ответить
            • Кстати, да. Даже упоковщик не нужен. )))
              Ответить
          • Да метр жалко, потому что потом 27 метров уйдет подлинковкой какой-нить wxWidgets.
            Ответить
    • автор, а можно узнать под какую платформу под какую ось на каком компиляторе писался код?
      а то мы тут спорим про разные платформы а скорее всего это было под виндоуз на вижуал си
      Ответить
      • Я не автор, но скорее всего под современную ось, а не 95 винду, так, что скорее всего delete вызоветься сам.
        Но не вызывать его, только из-за того, что в большинстве ОС он вызовиться сам - говнокодно.

        И деструктор всё-равно сам не вызоветься. У нас не C#!
        Ответить
        • delete не вызовется сам, так как у указателей нет конструкторов и деструкторов... для того чтоб вызвался деструктор, нужно обернуть в какой-нить умный указатель...
          Ответить
    • глобальные переменные - это плохо.
      голые указатели - это плохо.
      неоправданное применение static - это плохо.
      автору кода - строчно пройти курс живительной эвтаназии.
      Ответить
    • это не говнокод а дерьмо какое-то
      Ответить
      • может быть, но каменты рулят )))) 40% из них полнейшая чепуха, надеюсь люди сами не верят в то что пишут
        Ответить
    • Не смешнОЙ!
      Ответить

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