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

    +162

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    void Processing( void )
        {
        while ( moreToDo )
            {
            CData* temp = new CData; 
            GetData( temp ); 
            ProcessData( temp ); 
            delete temp; 
            }
        }

    Запостил: Говногость, 19 Июня 2010

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

    • Если GetData() и ProcessData() не генерят исключений, то жить будет.
      Ответить
      • Да ну, бред, выделять и освобождать память в цикле, когда это не требуется из-за того, что лень подчищать.
        Ответить
        • а если у CData в деструкторе чего делается? например освобождается то что GetData() туда положил. если структура данных не тривиальна, то часто проще все удалить.

          без контекста - не говно.
          Ответить
          • Ну под "подчисткой" я именно это и имел в виду.

            Я знаю, что в вашем плюсовом мире это считается нормальным, но лично мне это очень не нравится. Получается, что это вопрос стиля программирования.
            Ответить
          • его можно было выделять на стеке... говно в любом случае...
            Ответить
            • о, любитель стеков тут как тут!)
              Ответить
              • он прав. это специфика С++. Стековать всю жизнь.
                Ответить
                • если нужно иметь объект в нескольких местах - оверхедно копировать...
                  Ответить
                  • Если оверхедно копировать, то передавай по ссылке или по указателю. Какие проблемы?
                    Ответить
                  • А для маленьких объектов по указателю будет оверхеднее, чем копировать.
                    Ответить
            • без контекста не ясно, можно ли это выделять в стеке
              Ответить
              • ага, если внезапно 2 мегабайта. не вместится в стек.
                Ответить
                • тогда надо юзать auto_ptr, чтоб не чистить при выходе...
                  Ответить
                  • ты на auto_ptr'ах двинулся. тебе так сложно написать delete, что ты будешь по три слоя абстракции накручивать?
                    Ответить
                    • зато безопасно, и никто не забудет вызвать этот самый delete внезапным вызовом break.
                      Ответить
                      • но с другой стороны, если использовать тулзы на проверку memory leaks/invalid writes (типа валгринда), то они начинают тупить при выделенных в стеке объектах. вот у меня всё выделяется в куче (оверхеда не много, если оно не в бесконечном цикле), вручную удаляю, потом вижу в валгринде, где удалить забыл - и беспроблемно исправляю. в моём текущем проекте 100% нет утечек. а при стеке половина ошибок бы игнорировалась, в том числе invalid writes - и было бы потенциальное решето. так-то)))
                        Ответить
                        • >если использовать тулзы на проверку memory leaks/invalid writes (типа валгринда), то они начинают тупить при выделенных в стеке объектах
                          Это проблема тулз, а не кода. Найди кошерные тулзы. Лишь из-за проверки говнокодить...

                          >оверхеда не много, если оно не в бесконечном цикле
                          В бесконечном цикле оверхед быть не может по определению. Сколько не тупи в одной итерации цикла и не оверхедь - вычисления не закончатся никогда. А вообще бесконечных циклов не бывает.
                          Ответить
                          • > А вообще бесконечных циклов не бывает.

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

                            опять ты со своим девиантным пониманием слова "утечка".

                            A memory leak or leakage in computer science is a particular type of memory consumption by a computer program where the program is unable to release memory it has acquired. A memory leak has symptoms similar to a number of other problems (see below) and generally can only be diagnosed by a programmer with access to the program source code; however, many people refer to any unwanted increase in memory usage as a memory leak, though this is not strictly accurate.

                            Особенно последнюю часть зацени.
                            Ответить
                            • пример
                              каждую секунду расход памяти увеличивается на килобайт, через 6 часов работы программы, тот же функционал требует больших расходов памяти, но при выходе ликов нет... как называть это явление? я называю это утечками...
                              Ответить
                              • Это явление называется "программу писал дебил". С утечками не имеет ничего общего. Повторюсь - утечка это буквально когда перезаписывается указатель, но память перед этим не вычищается, в итоге мы теряем, за что уцепиться, т.е. мы принципиально никогда не сможем освободить тут память. Если мы можем освободить память в опр. момент времени - это не утечка, а логика программы.

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

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

                                    Потому что то, что ты приводишь в пример - это и есть логика прогрмамы!

                                    Иначе мне ясно, каким образом можно в языке со сборщиком мусора выделять память, которая не нужна, и при этом не возвращать её обратно в систему на протяжении 6 часов. Это невозможно.

                                    Если же память всё-таки нужна, то такова логика программы, не утечка это. Утечка это баг, т.е. что-то, чего программист не хотел. А тут он этого хотел. Да и пример-то надуманный.
                                    Ответить
                                    • я тебе написал пример, что одна и таже программа исполняет один и тот же функционал на 1 и 6 часах работы с разным расходом памяти... попробуй поищи программы в которых не так...
                                      я говорю, что это ошибки, ты говоришь, что это логика работы...
                                      Ответить
                                      • > я говорю, что это ошибки, ты говоришь, что это логика работы...

                                        это ошибочная логика работы )

                                        > попробуй поищи программы в которых не так...

                                        все такие программы написаны скорей всего на с++. там-то утечек навалом.
                                        Ответить
                                        • этого более чем хватает на всех языках... так как сборщик мусора может ничего не делать пока не забьется вся память, а пользователь он, сука, жадный... посчитает каждый байт на паре своих 4 гектарных планок...
                                          Ответить
                                          • > так как сборщик мусора может ничего не делать пока не забьется вся память

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

                                            > посчитает каждый байт на паре своих 4 гектарных планок...

                                            тут да, юзеры всегда смешат. покупают компьютер, чтобы проц простаивал и 99% ничего не делал, покупают оперативку, чтобы 90% было 90% времени свободно... компутер работает вхолостую...
                                            Ответить
                            • ну и по своим наблюдениям, вижу как каждый раз перед релизом, ребята из жава тимов судорожно ищут утечки памяти... у них нет тулзов для их поиска, так как реклама гласит, что в яве нет утечек... а вот мобильный телефон на котором запускают игру, думает совсем по другому...
                              Ответить
                              • Они не утечки ищут, а пытаются соптимизировать работу с памятью. Это разные вещи.
                                Ответить
                              • > вижу как каждый раз перед релизом, ребята из жава тимов судорожно ищут утечки памяти...

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

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

                                    > у них нет тулзов для их поиска, так как реклама гласит, что в яве нет утечек.

                                    ребята про профайлеры не слышали?
                                    Ответить
                                    • > ребята про профайлеры не слышали?
                                      незнаю... не код же они пересматривают строку за строкой...

                                      всегда завидовал и наверное буду завидовать и дальше тем, у кого есть время писать сначала плохо а потом хорошо... у нас в индустрии платят только за хорошо и сразу, со второй попытки написать хорошо может каждый имбицил...
                                      Ответить
                                      • ну если пирожки печёшь - то вполне возможно и так
                                        Ответить
                                        • пекари и специалисты по шаурме тоже попадаются, говоря что есть питон/шарп и на них можно печ пирожки в виде ААА-шутеров убийц крайзиса... вот только первый мейлстоун их резко убеждает в обратном...
                                          разработка движка на питоне от специалиста с многолетним стажем длилась дольше разработки игры на С++, при несравнимо разных показателях производительности и расхода памяти...
                                          Ответить
                                          • > разработка движка на питоне от специалиста с многолетним стажем длилась дольше разработки игры на С++

                                            по времени разработки тут всё-таки сравниваются не языки/системы, а профессионализм разрабов. всё-таки, каким бы с++ не был говном, с++ник допустим с 5-летним стажем куда подкованнее питониста с тем же стажем.
                                            Ответить
                        • в хорошей программе на С++ delete практически не используется и многие программисты считают его частое использование проблемами в архитектуре...
                          Ответить
                          • Бред несёшь. new нужен там, где есть динамика, и нельзя предаллоцировать. "многие программисты считают его частое использование проблемами в архитектуре" - это какие-то дебилы-хелловорлдщики так считают.
                            Ответить
                            • отсутствие delete не значит наличие утечек... если ты в первые в жизни слышишь такую фразу, значит ты полный нуб в С++, программировании и вообще...
                              Ответить
                            • отсутствие delete не означает что нельзя делать new... delete обычно вызывается неявно, и практически всегда понятно в какой момент он вызывается...
                              Ответить
                          • > в хорошей программе на С++ delete практически не используется и многие программисты считают его частое использование проблемами в архитектуре.

                            ну а допустим есть игорвое поле, и на нём может быть произвольное количество объектов с произвольным количеством отношений, свойств и т. п. ты это через стек или мемпул будешь делать? или делать спецификацию "максимум 4 стула на карте?" для казуалок-то/хелловорлдов-то пойдёт, но не для чего-то большого, серьёзного
                            Ответить
                            • я нигде не говорил про запрет new...
                              я говорю что в грамотной программе нет delete... есть места в которых оно удаляется... само... автоматически...
                              а есть места где явно вызывается Release...

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

                                только вот

                                > я говорю что в грамотной программе нет delete... есть места в которых оно удаляется... само... автоматически...

                                есть взаимоисключащий параграф со многими твоими высказываниями в стиле "в сборщике мусора память удаляется автоматически, это говно и утечки"
                                Ответить
                                • я не говорю про сборшик мусора... это не сборщик... это обертки над указателями, которые удаляют объекты в конце блоков видимости...
                                  типа auto_ptr... эти оберткам пофиг кто на кого ссылается... у объекта есть время жизни, закончилось - досвиданья, все обращения к объекту после конца времени жизни - ошибки и их быть не должно...
                                  Ответить
                  • а auto_ptr точно будет очищаться в таком цикле каждый раз?
                    Ответить
                    • 100%...
                      можно 1 раз выделить перед циклом буфер sizeof(CData) и через placement new создавать в этом буфере объект...
                      Ответить
                      • как-то неинтуитивно а то - ведь будучи в цикле, мы как бы за пределы видимости не выходим а остаёмся внутри )
                        Ответить
                        • конченый, почитай про циклы в С++, а потом проецируй свой больной разум в буквы.
                          Ответить
      • Генерят.))))
        Ответить
    • говно-гну идентейшен детектед, столлман доволен.
      Ответить
    • здравствуйте, я аутист.

      так вот, это не говнокод, покуда нет контекста. конструктор может быть переопределён под пул... даже если исключения генерятся, то пул может определять потерянные участки.

      привет.
      Ответить
    • А moreToDo туду может блокировать поток в каком-то месте, ожидая что-то, например.
      Ответить
    • MaxPro detected:
      http://www.gotdotnet.ru/forums/4/85696/406946/#post406946
      Ответить
      • "if isnumeric(textbox1.text) then response.write("true") else response.write("false")
        Это Бэйсик. В других языках гораздо геморойнее."

        ухаха
        Ответить
        • Я тоже чуть не оборжался.
          зы: Я не усрус. Нашёл совершенно случайно. Казалось бы, какова вероятность, что когда ищешь про tryParse гуглом и наткнёшься на макса про. Можно конечно подумать, что это кто-то другой, но я почему-то узнал его код сразу. Видел его здесь столько раз. :D
          Ждём Усруса, что-бы удостоверл, что это действительно максим прохоров. :)
          Ответить
          • да это он, сам урсус как-то давал ссылки в туда особенно эот

            http://www.aspnetmania.com/Forums/ForumMessage/459468.html
            Ответить
            • Дак макс про 35 лет? Я думал ему 9...
              Ответить
              • небезызвестному vbnet2000'у и вовсе 47.

                но с другой стороны: ДенисПопов, Вебкил...

                Быдлокодингу все возрасты покорны
                Ответить
                • А что-за денис попов? я чёта о нем не слышал на говнокоде. Хотя макс про, усрус, вебкилл знаю.
                  Ответить
                  • > А что-за денис попов?

                    http://lurkmore.ru/Денис_Попов
                    Ответить
                • http://www.gotdotnet.ru/forums/4/85662/
                  Ответить
          • вот например суровыйдизайн макса:

            http://s49.radikal.ru/i124/0904/df/53506fd6f130.png
            Ответить
            • Дак он суров! %)
              Ответить
              • бля не то слово, он просто убийца

                это взорвало мой мозг, его даже говнодизайном не назовешь
                Ответить
                • заметь, в заголовке окна анаписано: "2 часть"

                  то есть где-то ещё есть первая..
                  Ответить
            • Сделайте меня развидеть это!
              Ответить
          • Это действительно Макс Прохоров.
            Его треды доставляют на sql.ru
            в данный момент ловим на живца http://sql.ru/forum/actualthread.aspx?tid=787435
            Ответить
      • "Попробовал в .NET применить функцию IsNull. Интерпретатор ругается, пишет, что слово не декларировано. Странно, в книжках ничего такого нет. В VB6 всё работало. Потом попробовал функцию IsNumeric - работает. Может эти гады заменили Null на Nothing?
        С уважением,
        Макс "
        Ответить
        • Это где такое? В другой теме?
          зы: Я специально не искал. Видел только одно его сообщение, то что приведено по моей ссылке.
          Ответить
          • Да у него много тм сообщений на сайте ж можно посомтреть.
            Ответить
          • Ыыы. Загуглил на "гость max pro" (без ковычек).
            http://www.gotdotnet.ru/forums/4/116360/548956/#post548956
            Ответить
        • жестяк
          Ответить

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