- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
void Processing( void )
{
while ( moreToDo )
{
CData* temp = new CData;
GetData( temp );
ProcessData( temp );
delete temp;
}
}
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+162
void Processing( void )
{
while ( moreToDo )
{
CData* temp = new CData;
GetData( temp );
ProcessData( temp );
delete temp;
}
}
без контекста - не говно.
Я знаю, что в вашем плюсовом мире это считается нормальным, но лично мне это очень не нравится. Получается, что это вопрос стиля программирования.
Наверное, это что-то пидарасистское?
Это проблема тулз, а не кода. Найди кошерные тулзы. Лишь из-за проверки говнокодить...
>оверхеда не много, если оно не в бесконечном цикле
В бесконечном цикле оверхед быть не может по определению. Сколько не тупи в одной итерации цикла и не оверхедь - вычисления не закончатся никогда. А вообще бесконечных циклов не бывает.
с позиции программы - бывают. цикл не закончился на момент завершения программы (юзер убил в таскбаре) - у цикла не было конца, он бесконечен.
опять ты со своим девиантным пониманием слова "утечка".
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 часов. Это невозможно.
Если же память всё-таки нужна, то такова логика программы, не утечка это. Утечка это баг, т.е. что-то, чего программист не хотел. А тут он этого хотел. Да и пример-то надуманный.
я говорю, что это ошибки, ты говоришь, что это логика работы...
это ошибочная логика работы )
> попробуй поищи программы в которых не так...
все такие программы написаны скорей всего на с++. там-то утечек навалом.
забивается не вся память, а только предвыделенный участок кучи. если ты не в курсе, то сишные и сиплюшные дефолтны аллокаторы тоже предвыделяют память у системы в приличных месштабах. так что технически разницы нет -и там и там висим с неиспользуемой памятью. вот только сишный аллокатор из-за дефрагментации будет выделять ещё и ещё сегментов (если софт работает скажем 100 суток), а сборщик мусора будет сжимать.
> посчитает каждый байт на паре своих 4 гектарных планок...
тут да, юзеры всегда смешат. покупают компьютер, чтобы проц простаивал и 99% ничего не делал, покупают оперативку, чтобы 90% было 90% времени свободно... компутер работает вхолостую...
вообще во всех языках так делают - сначала пишут, а потом перед релизом проверяют слабые места и оптимизируют (писать сразу же оптимизируя считается моветоном). прямо уж судорожно? если сроки издатель зажимает, то это не вина явы)
причем заметь, я не говорил про "оптимизировать", я говорил про явные ошибки и недочеты в архитектуре...
вообще-то я говорил, что сначала нужно писать программу не намеренно плохо, а "как пишется" - и уже когда есть рабочий прототип - только тогда начинать тестить на боттлнеки и их убирать. Это во всех умных книжках пишут, вообще-тто (что-тов роде "не оптимизируй раньше времени"). т.е. это совершенно нормально, что они ищут слабые места в уже почти готовом продукте и пытаются урезать потребление памяти. и непонятно, как это невинное занятие позволяет утверждать, что в яве есть утечки памяти. логика типа "если Маша хочет выглядеть лучше - значит, в настоящий момент она мымра мымрой" - логика настоящего с++ника.
> у них нет тулзов для их поиска, так как реклама гласит, что в яве нет утечек.
ребята про профайлеры не слышали?
незнаю... не код же они пересматривают строку за строкой...
всегда завидовал и наверное буду завидовать и дальше тем, у кого есть время писать сначала плохо а потом хорошо... у нас в индустрии платят только за хорошо и сразу, со второй попытки написать хорошо может каждый имбицил...
разработка движка на питоне от специалиста с многолетним стажем длилась дольше разработки игры на С++, при несравнимо разных показателях производительности и расхода памяти...
по времени разработки тут всё-таки сравниваются не языки/системы, а профессионализм разрабов. всё-таки, каким бы с++ не был говном, с++ник допустим с 5-летним стажем куда подкованнее питониста с тем же стажем.
ну а допустим есть игорвое поле, и на нём может быть произвольное количество объектов с произвольным количеством отношений, свойств и т. п. ты это через стек или мемпул будешь делать? или делать спецификацию "максимум 4 стула на карте?" для казуалок-то/хелловорлдов-то пойдёт, но не для чего-то большого, серьёзного
я говорю что в грамотной программе нет delete... есть места в которых оно удаляется... само... автоматически...
а есть места где явно вызывается Release...
и я тебе больше скажу... если ты уверен что на карте есть больше 4 стульев, это еще не значит что их не 4...
только вот
> я говорю что в грамотной программе нет delete... есть места в которых оно удаляется... само... автоматически...
есть взаимоисключащий параграф со многими твоими высказываниями в стиле "в сборщике мусора память удаляется автоматически, это говно и утечки"
типа auto_ptr... эти оберткам пофиг кто на кого ссылается... у объекта есть время жизни, закончилось - досвиданья, все обращения к объекту после конца времени жизни - ошибки и их быть не должно...
можно 1 раз выделить перед циклом буфер sizeof(CData) и через placement new создавать в этом буфере объект...
так вот, это не говнокод, покуда нет контекста. конструктор может быть переопределён под пул... даже если исключения генерятся, то пул может определять потерянные участки.
привет.
Это Бэйсик. В других языках гораздо геморойнее."
ухаха
зы: Я не усрус. Нашёл совершенно случайно. Казалось бы, какова вероятность, что когда ищешь про tryParse гуглом и наткнёшься на макса про. Можно конечно подумать, что это кто-то другой, но я почему-то узнал его код сразу. Видел его здесь столько раз. :D
Ждём Усруса, что-бы удостоверл, что это действительно максим прохоров. :)
http://www.aspnetmania.com/Forums/ForumMessage/459468.html
но с другой стороны: ДенисПопов, Вебкил...
Быдлокодингу все возрасты покорны
http://lurkmore.ru/Денис_Попов
http://s49.radikal.ru/i124/0904/df/53506fd6f130.png
это взорвало мой мозг, его даже говнодизайном не назовешь
то есть где-то ещё есть первая..
Его треды доставляют на sql.ru
в данный момент ловим на живца http://sql.ru/forum/actualthread.aspx?tid=787435
С уважением,
Макс "
зы: Я специально не искал. Видел только одно его сообщение, то что приведено по моей ссылке.