Зачем нужны GC, Java, .NET?

Почитал тред. Поржал. Любители GC как всегда демонстрируют некомпетентность вообще и абсолютное незнание языков без gc в частности. Но это так, лирика.

Для справки: в моём последнем проекте на c++ из всех ссылок и указателей только 2% - умные с подсчётом ссылок, остальные - T*, T& и auto_ptr<T>. При использовании этих shared_ptr только в 20% случаев упоминания они собственно обращаются к своему счётчику, остальное - разыменования и прочее. Нехитрая арифметика показывает, что только в 0.1% случаев (не считая до%уища стековых переменных) мне потребовалась функциональность, схожая с GC.

/thread.

> Агитировать за что-либо (за лисп в данном случае) обсирая всех и вся вокруг могут только законченые дауны. Антирекламу лиспу делаешь хорошую на ЛОРе.

дух антихриста заклинаю тебя! залогинься! :)

PS последний раз такой «пинг понг» (скорее всего со стеной :) я читал в его исполнении :)

> T*, T& и auto_ptr<T>

Это наверно называется «ортогональность».

Нехитрая арифметика показывает, что только в 0.1% случаев (не считая до%уища стековых переменных)

std::vector<int> - это стековая переменная? А int[10]?

Вы не поверите, но { std::vector<int> f; } в том числе и стековая переменная. И там абсолютно нет подсчёта ссылок.

>Вы не поверите, но { std::vector<int> f; } в том числе и стековая переменная.

А ничего что данные хранятся в куче?

И там абсолютно нет подсчёта ссылок.

Да, он очень рационально делает O(N) копирование при возвращении его как результата.

> Да, он очень рационально делает O(N) копирование при возвращении его как результата.

Возвращай через аргументы функции по ссылке, можно swap'ом. Если так сильно хочется return - используй QVector или любой другой контейнер с copy-on-write и счетчиком ссылок.
Вообще, в процессе дискуссии твои аргументы постепенно трансформируются из глобальных и голословных в совсем уж мелочное нытье. Тебя, наверное, все родственники ненавидят :)

>Возвращай через аргументы функции по ссылке, можно swap'ом.

И после этого плюсофаги исходят на говно от комментариев какого-то нуба на rsdn о том что он хочет аргумент operator+() модифицировать.

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

Ну какбы в любом языке есть много мелких неприятностей. Например, в жаве с колбэками ради которых надо городить целый интерфейс. Или в разное унаследованное говно в Си типа gets(). Но только в С++ threshold мелких неприятностей способных довести персонально меня до белого каления превышен процентов на десять-двадцать. И при этом что чего-то дальновидного и прорывного в языке нет совсем.

> Но только в С++ threshold мелких неприятностей способных довести персонально меня до белого каления превышен процентов на десять-двадцать.

Давай свой top 10 - просто интересно.

Для справки: в моём последнем проекте на c++ из всех ссылок и указателей только 2% - умные с подсчётом ссылок, остальные - T*, T& и auto_ptr<T>.

А сколько процентов времени работы над проектом было потрачено на то, чтобы решить, когда нужно использовать T*, когда T&, когда auto_ptr, когда scoped_ptr, когда shared_ptr, когда weak_ptr, когда может даже intrusive_ptr. Для краткости не будем затрагивать массивы.

>auto_ptr,scoped_ptr,shared_ptr,weak_ptr,intrusive_ptr (бла-бла-бла)

А как драматично звучит. Не нравиться, не используй. Ведь никто не заставляет использовать весь этот зоопарк. Некоторые из этих вещей я впервые вижу. А ведь писал как-то до этого программы на С++. Большинство нормальных С++ программистов обходятся оптимальным минимумом сущностей, а не пытаются яростно юзать все фичи языка.

Дураки из любого языка монстра сделают. Вы просто подождите немного. Про С# в недалеком будущем будут говорить то же, что про С++ сейчас. Я уже сейчас вижу как некоторые «овощи» извращаются с System.Reflection.

З.Ы. Есть розетка в доме. Если сунуть пальцы в розетку будет «плохо». Отсюда вывод: электрические розетки в домах - зло. Их надо в срочном порядке убирать.

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

А и в качестве аргумента против розеток говорите, что и ее можно «засегфольтить» сунув туда пару вязальных спиц.

Оптимальный минимум сущностей от С++ - С, имхо :)

Твоя аналогия - говно. Речь должна идти не о ссаных розетко-кнопочках, а как минимум о распределительном щите, в котором «любые небыдлокодеры» любят ковыряться без «резиновых перчаток», а потом плакать и ругаться на форумах.

Love5an, скажите, пожалуйста, Вы занимаетесь программированием на каком-либо языке семейства LISP (Common Lisp, Scheme) профессионально? Является ли это основным родом Вашей деятельности? Спасибо.

Kuka vs Love5an. чёрт возьми, где мой попкорн?

Для справки: в моём последнем проекте на c++

иными словами, из треда ты не понял вообще ничего

Большинство нормальных С++ программистов обходятся оптимальным минимумом сущностей, а не пытаются яростно юзать все фичи языка.

большинство об этих фичах просто не знает, и знать не хочет

>Твоя аналогия - говно.

мило, очень мило =)

Речь должна идти не о ссаных розетко-кнопочках, а как минимум о распределительном щите, в котором «любые небыдлокодеры» любят ковыряться без «резиновых перчаток», а потом плакать и ругаться на форумах.

Этим занимаются электрики(в нашем случае писатели низкоуровневых либ). На выходе все уже должно быть защищено от короткого замыкания. И если я расставляю мебель по комнате и технику бытовую я не хочу даже думать о том, что тягая кресло я получу занозу, а подключая телевизор спалю нахрен дом. Абстракция, батенька, абстракция.

>А сколько процентов времени работы над проектом было потрачено на то, чтобы решить, когда нужно использовать T*,

А мало. В большинстве случаев правила простые:

если функция принимает объект на «попользоваться» - то ссылкой

если некая фабрика что-то генерит и обязательно в куче - возвращаем указатель. Что с ним делать решит вызывающая функция.

если надо иметь указатель локально или как член класса - это тупо auto_ptr.

Вот и всё. Утечек нет, головной боли нет, тормозов нет.

>иными словами, из треда ты не понял вообще ничего

GC не нужен, что ещё надо понимать? Про то, что компиляция в байткод не нужна и так понятно, итого Java и .NET тоже не нужны, ибо других значимых фич в них нет.

GC не нужен, что ещё надо понимать?

тот факт, что использование GC при избытке хип-памяти может повысить производительность приложения, прошёл мимо твоего сознания?

Неиспользование free и соответственно упрощённый malloc могут ещё сильнее повысить производительность. А ещё у нас есть быстрый-быстрый стек искаропки, а у вас?

>Вот и всё. Утечек нет, головной боли нет, тормозов нет.

Давай начнем с выяснения такого вопроса:

а) Чудеса бывают
б) Чудес не бывает.

>Неиспользование free и соответственно упрощённый malloc могут ещё сильнее повысить производительность.

А так собственно программы с появления компьютера и писались: Вся память разбивалась на буфера фиксированного размера под разные нужды и юзалась безо всякого malloc/free.

если некая фабрика что-то генерит и обязательно в куче - возвращаем указатель. Что с ним делать решит вызывающая функция.

Прелесть какая, вызывающая функция забьёт/кинет исключение и получим утечку памяти.

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

Неиспользование free и соответственно упрощённый malloc могут ещё сильнее повысить производительность

а регионы - ещё сильнее. вот только для того, чтобы делать такие заявления, их надо подкреплять какими-нибудь исследованиями. в пользу своей позиции я ссылки приводил - а тебе есть что сказать?

А ещё у нас есть быстрый-быстрый стек искаропки, а у вас?

извини, но ты идиот? что ещё за «мы» и «вы»? речь идёт о технологиях, вообще-то - не о Монтекки и Капулетти, и не об истории холодной войны

>Прелесть какая, вызывающая функция забьёт/кинет исключение и получим утечку памяти.

Конструктор auto_ptr исключения не кидает. А игнорирование результата, возвращаемого фабрикой случается только если программа пишется методом миллиарда мартышек. Ещё высосанные из пальца возражения будут?

>а регионы - ещё сильнее.

Стёб ты не понял.Разъясняю доступно: если просто бездумно жрать лишнюю память, то каждый лишний попугай скорости будет стоить слишком много этой самой памяти. В большинстве случаев GC тормозит, не давая профита, а там где прибавка производительности таки есть (по сравнению с решением «в лоб» на языке без GC) - разумнее всё равно соптимизировать вручную, использовав пулы. Или забить. Итого GC не нужен.

Кстати, мусорособирательные пионеры, есть такой язык, где не только освобождать память не надо, но и выделять, и объявлять переменные тоже не надо, компилятор достаточно интеллектуален, чтобы сделать это за вас! Полная свобода от этой рутины. Называется язык gwbasic. Оч рекомендую.

> Называется язык gwbasic. Оч рекомендую.

Как же так случилось, что ты с ним знаком, брезгливый учёный ты наш?

Ну а как-же? Надо следить за тендециями развития технологий. Вот сишарп лет через 15 превратится как раз в gwbasic с миллионом встроенных типов и гигабайтным рунтаймом.

> мило, очень мило =)

чмаффки)))))))))))))))))))))

Этим занимаются электрики (в нашем случае писатели низкоуровневых либ)

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

Абсурдище, не игнорь меня. Я хочу видеть top 10 «мелких неприятностей C++, способных довести персонально тебя до белого каления». Хотелось бы знать из-за чего столько душевных страданий.

> тот факт, что использование GC при избытке хип-памяти может повысить производительность приложения, прошёл мимо твоего сознания?

Забавно, ты озвучил следствие из основного недостатка GC, а преподнес его как преимущество.

>Я хочу видеть top 10 «мелких неприятностей C++, способных довести персонально тебя до белого каления».

Не хочу повторяться.

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

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

>Это то точно будет повторением: плюсов в плюсах выше крыши

Кресты - лишь куча костылей вокруг Си. При чем их туда все больше и больше тащат.

Забавно, ты озвучил следствие из основного недостатка GC, а преподнес его как преимущество.

может потому, что оно им является?

если просто бездумно жрать лишнюю память

а если не бездумно?

В большинстве случаев GC тормозит, не давая профита

а что-нибудь кроме общих фраз ты выдать в состоянии? что это за «большинство случаев», каков «профит»? ты вообще технарь, или дорвавшийся до интернетов филолог?

разумнее всё равно соптимизировать вручную, использовав пулы

но вообще я, кажется, понял, что в твоём случае означает «разумнее». «разумнее» - это когда не надо напрягать гипертрофированный надглоточный ганглий, принимая решение по используемой модели памяти. ведь и так всё очевидно - Java тормозит, C++ не тормозит; GC тормозит, malloc/free не тормозят

а лучше всего вообще писать на FORTRAN

>а если не бездумно?

А если не бездумно - то это вручную получается.

а что-нибудь кроме общих фраз ты выдать в состоянии?

см выше статистику по живому проекту.

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

Я-то принимаю решение, а не тупо полагаюсь на сборщик и гигагерцы и гигабайты железа юзера.

А если не бездумно - то это вручную получается

fail. писать собственный GC никогда не приходилось, да?

Я-то принимаю решение, а не тупо полагаюсь на сборщик и гигагерцы и гигабайты железа юзера.

то есть я всё понял правильно :)

>Для справки: в моём последнем проекте на c++ из всех ссылок и указателей только 2% - умные с подсчётом ссылок, остальные - T*, T& и auto_ptr<T>. При использовании этих shared_ptr только в 20% случаев упоминания они собственно обращаются к своему счётчику, остальное - разыменования и прочее. Нехитрая арифметика показывает, что только в 0.1% случаев (не считая до%уища стековых переменных) мне потребовалась функциональность, схожая с GC.

это не статистика :) статистика это цифры, цифры количества цифры скорости выполения, занимаемой памяти, а ещё лучше к этому сравнение с другими технологиями. А так это просто слова.

Байткод нужен, чтобы можно было запускать web аппликухи без какой либо перекомпиляции (что пользуется для апплетов, и всяких авторизаций). + Лишний слой защиты от мудрых программистов, которые будут рады заюзать недокументированные функции или баги системы, что в итоге переносимость пострадает. Теоритически весь профит байткода, _можно_ заменить либами под все оси, однако на практике этого не получается, так уж код пишут. Вот санки и сделали вариант, при котором у программиста просто нет возможности обойти ява машину, что даёт некий бонус защищённости от программиста.

> А сколько процентов времени работы над проектом было потрачено на то, чтобы решить, когда нужно использовать T*, когда T&, когда auto_ptr, когда scoped_ptr, когда shared_ptr, когда weak_ptr, когда может даже intrusive_ptr. Для краткости не будем затрагивать массивы.

auto_ptr и scoped_ptr - это одно и то же. Практически это T*, только delete самому вызывать не надо.

intrusive_ptr - тот же shared_ptr, только счетчик ссылок объявляешь сам. Применяется только для оптимизации и извращений. weak_ptr - для разрыва циклов. Если он нужен, то очевидно где он должен быть.

Отличия T& от T* только в синтаксисе. Итого реальных варианта 2: либо область жизни объекта ограничена стеком, тогда используется scoped_ptr и компания, либо наличием «пользователей» - тогда shared_ptr.

И даже тут выбор почти всегда очевиден из выбранной структуры данных и архитектуры приложения.

Ты лучше расскажи, сколько времени уходит на тонкий тюнинг GC, чтобы приложением можно было пользоваться. Например, подбор опций командной строки типа -Xmx и -Xms, ручное дергание GC в нужные моменты (определяются методом проб и ошибок), написание костылей для перезапуска упавшего от segfault'а в GC приложения и прочие «мелочи», ставшие рутиной для managed-разработчиков. Наблюдал за этим цирком со стороны, мне было их так жалко...

>плюсов в плюсах выше крыши и все, кто осилил их хорошо знаю

Плюсов в оценках вида «3+», скажем так

Отличия T& от T* только в синтаксисе

да ну?

>да ну?

Ну да. Единственное отличие - в том, что T& не принято инициализировать нулём.

>Плюсов в оценках вида «3+», скажем так

Я прямо вижу, как ты записываешь себе в блокнотик: «похожесть на java: 3+»

Есть такое дело. Более того, это практически норма во многих C++ приложениях и библиотеках.

Но вопрос в том, что именно считать утечкой памяти. Википедия утверждает, что «A memory leak is ... type of memory consumption ... where the program is unable to release memory it has acquired». Для программиста это определение неполно - в нем не говорится, КОГДА должна освобождаться память. Ведь при завершении приложения память в любом случае освободится.

Если принять, что память должна освобождаться сразу, то managed-программы текут by design. На роль определения это не подходит.

Я в свое время пришел к выводу, что термин «утечка памяти» неточен и не нужен. Надо смотреть в корень проблемы - приложения не должны «падать» из-за нехватки памяти, которая реально не используется.

Многие «утечки памяти» безвредны. Например (в диалоге открытия файла):

int read_file() { ... char * header = malloc(1024);

...(читаем заголовок файла)...

if (header[0] != 'P' || header[1] != 'E') return 0;

...(работаем с полями заголовка)...

free(header); ... return 1; }

Память утекает если пользователь выбрал файл неверного формата. Но диалог даже не покажет ему эти файлы. Даже если он ухитрится их открыть, утечет аж килобайт памяти. Такую «утечку» никто даже не заметит.

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

Мне приходилось поддерживать много разного кода, в том числе код 30-летней давности. Даже не вспомню, когда реальные баги были из-за «порчи стека и кучи и прочих областей памяти». Была пара похожих случаев, и я тратил час-другой на раскапывание дампов памяти и возню в отладчике. А настоящая причина была в другом месте.

Не так страшны «утечки», как разговоры о них. Не возмущались бы любители managed-сред, что в C/С++ «утечки памяти и переполнения буферов», реальные баги было бы проще искать. А то при каждом неочевидном баге кажется всякое, и ищещь не там где надо.