[C++?] Серьезный вопрос.

>Опять плюсофильские софизмы вроде "поскольку полуполное это полупустое, то полное это пустое".

Ога. Уже не 99%, а только полуполное, т.е. 50%. Скоро дойдём до правильной оценки влияния наличия gc на качество программ.

>Ошибки такого рода не доходят даже до бета-тестеров.

Кто гарантирует?

>Это сознательная ложь: объекты надо постоянно передавать вовне, в чужой код.

Это я тебя передразнивал. Так что да, ложь, как и исходное высказывание.

>Он AST-дерево C++- проекта наверно перестраивает

Какая разница что он делает (а открыт проект на жабке в жалкие пицот строу), если на это время он повисает?

>>А что такое "управление памятью в RT-стиле"?

> Работа с пулами. В С++ ее просто нет.

Покажи мне язык, в котором она есть.

> На возможное плюсофильское вякание по поводу перегруженных new/delete есть замечательная цитата Изи Крейнина выше по треду.

На вышеприведенное плюсофобское вякание выше по треду тоже найдется куча цитат (мне просто искать лень).

>Приложения на С++ в своп не уходят?

На сравнимых задачах - нет. И на более сложных тоже.

>Это ошибка уже другого рода которая решается чисто механистически

Дык и памятью в c++ управляют "чисто механистически".

>А что, АО не очевидно, что GC спасает от утечек памяти

Судя по потреблению памяти программами на питоне, дотнете и яве - нет.

>Что классические утечки случаются чаще, чем логические?

"Классические" утечки заканчиваются ко второму курсу. Так что нет, не чаще.

> На сравнимых задачах - нет.

А на С++ есть IDE, сравнимое с Eclipse, Netbeans или IDEA?

>А на С++ есть IDE, сравнимое с Eclipse, Netbeans или IDEA?

По отзывчивости интерфейса? Сам то как думаешь. Нюанс: свистоперделки не приносят радости, если вешают программу на секунду на каждое движение мышью.

> Судя по потреблению памяти программами на питоне, дотнете и яве - нет.

Что "нет"? Тебе не очевидно, что потребление памяти и утечки -- вещи сугубо перпендикулярные? Мне тебя жаль.

> "Классические" утечки заканчиваются ко второму курсу. Так что нет, не чаще.

Очередной гениальные проектировщик хеллоуворлдов? То-то valgrind выдумывали, а теперь все радостно его активно используют... Наверное, они все первокурсники, один legolegs во всём белом на втором курсе уже.

>>Опять плюсофильские софизмы вроде "поскольку полуполное это полупустое, то полное это пустое".

>Ога. Уже не 99%, а только полуполное, т.е. 50%. Скоро дойдём до правильной оценки влияния наличия gc на качество программ.

Виляние.

>>Ошибки такого рода не доходят даже до бета-тестеров.

>Кто гарантирует?

Напиши хоть что-нибудь кроме виляния. Факт из практики, например. Как вы обмениваетесь хэндлами открытых сокетов через пяток-другой бакендов туда и обратно, например.

>>Это сознательная ложь: объекты надо постоянно передавать вовне, в чужой код.

>Это я тебя передразнивал. Так что да, ложь, как и исходное высказывание.

Это я вообше не понял.

>>Он AST-дерево C++- проекта наверно перестраивает

>Какая разница что он делает (а открыт проект на жабке в жалкие пицот строу), если на это время он повисает?

Это подражание gaa такое - сравнение существующих IDE с несуществующими?

>>Это ошибка уже другого рода которая решается чисто механистически

>Дык и памятью в c++ управляют "чисто механистически".

Нет, не управляют. Несостоятельность идеи RAII я доказал в этом треде раза два. Давай третий раз:
Посылка 1: код который пишется в данный момент должен зависеть от стабильного API и не зависеть от нестабильного.
Посылка 2: RAII-обертки пишутся тоже в данный момент времени и поэтому они нестабильны.

Следствие: RAII вызывает противоречие, и поэтому оно несостоятельно. ЧТД.

>> Работа с пулами. В С++ ее просто нет.

>Покажи мне язык, в котором она есть.

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

>На вышеприведенное плюсофобское вякание выше по треду тоже найдется куча цитат (мне просто искать лень).

Нет, не было.

>потребление памяти и утечки -- вещи сугубо перпендикулярные?

И практически и теоретически это - взаимосвязанные вещи.

>Мне тебя жаль.

В ход пошли Серьёзные Аргументы™.

>То-то valgrind выдумывали, а теперь все радостно его активно используют

Используют, да. И он пишет "no leaks". А кто тебе пишет "ни одного дескриптора не просрано, ни один файл не был записан не полностью, ни один временный файл не остался, кислое не сравнивалось с мягким", чтоб ты спокойно спал по ночам?

>Виляние.

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

>Факт из практики, например.

Потребовалось распараллелить задачу хитрым образом, написал свой менеджер потоков (системных). Слава raii, всё заработало, ничего не утекло, отладка не потребовалась.

>Это подражание gaa такое - сравнение существующих IDE с несуществующими?

Это kdevelop не существует? Или может вижлстудия, на которую все вантузятники дрочат и половина линуксоидов?

>>> Работа с пулами. В С++ ее просто нет.

>> Покажи мне язык, в котором она есть.

> В Си можно организовать.

То есть организовать это в Си можно, а в Си++ - уже противоречит заветам (непонятно чьим)? Зашибись логика.

>>потребление памяти и утечки -- вещи сугубо перпендикулярные?

> И практически и теоретически это - взаимосвязанные вещи.

Дооо, программа, потребляющая на всей протяжённости своей жизни ~500Mb и утечки -- это очень взаимосвязанные вещи.

> В ход пошли Серьёзные Аргументы™.

Это не аргумент, а констатация факта.

> Используют, да. И он пишет "no leaks".

А-а-а... valgrind'а ты тоже не видел. Он пишет 'possibly lost', 'definitely lost' и так далее. А 'no leaks' он не пишет.

> А кто тебе пишет "ни одного дескриптора не просрано, ни один файл не был записан не полностью, ни один временный файл не остался, кислое не сравнивалось с мягким", чтоб ты спокойно спал по ночам?

Да, ремень и подушки -- говно, потому что не кричат, что тормоза полетели, а из-за угла сейчас вывернет придурок на камазе.

>Нет, не управляют. Несостоятельность идеи RAII я доказал в этом треде раза два.

Посчитай сколько раз тебе доказали бесполезность gc.

>Посылка 1

Код для RAII тривиален. Даже в тех редких случаях, когда он не стабилен, он всё равно получается на века. И даже если он меняется исправления просто крошечные.

>Посылка 2

Сх$яли?

>Следствие

Твои посылки говно, ты ничего не понимаешь в посылках.

>Тебе ясно показывают, что gc не предотвращает серьёзные ошибки (ошибочные результаты, потерю данных, падения, зависания и т.д.),

Потеря данных, падения и зависания таки почти всегда происходят из-за ошибок работы с памятью .

>Потребовалось распараллелить задачу хитрым образом, написал свой менеджер потоков (системных).

Oh My God, ты еще один унылый тредпул написал?

>>Это подражание gaa такое - сравнение существующих IDE с несуществующими?

>Это kdevelop не существует?

Судя по тредам вида "когда ж его допилят" я не питаю особого энтузиазма к этому проекту.

>Или может вижлстудия, на которую все вантузятники дрочат и половина линуксоидов?

MS ее писала лет пятнадцать. Шестая регрессировала к редактору уровня gedit через несколько часов работы, например.

>>> Покажи мне язык, в котором она есть. >> В Си можно организовать. >То есть организовать это в Си можно, а в Си++ - уже противоречит заветам (непонятно чьим)?

В С++ ее можно организовать только с POD-структурами. Все хваленое ООП сразу идет лесом.

>А 'no leaks' он не пишет.

Тролли совсем обнаглели: http://img-fotki.yandex.ru/get/3805/legolegs.0/0_15b33_b43d3477_orig

>Да, ремень и подушки -- говно

Надоели уже ваши кривые аналогии. gc - это бочка с желе, и точка.

>Потеря данных, падения и зависания таки почти всегда происходят из-за ошибок работы с памятью .

Правда? А UnhandledException мы, значит, за падение не считаем? дедлоки (львиная доля которых невозможна при использовании RAII) - это тоже что-ли ошибки памяти?

>Судя по тредам вида "когда ж его допилят" я не питаю особого энтузиазма к этому проекту.

Смотри на это с другой стороны: даже недопиленный он лучше этих ваших эклипсов.

>>Нет, не управляют. Несостоятельность идеи RAII я доказал в этом треде раза два.

>Посчитай сколько раз тебе доказали бесполезность gc.

Нет, не доказали. Были только софизмы про полуполное и полупустое и про свободу от греха, не во грехе.

>Код для RAII тривиален.

Какбе нужно не допускать протечки абстракций. ООП должно покрывать все аспекты работы с инкапсулированным ресурсом.

>Даже в тех редких случаях, когда он не стабилен, он всё равно получается на века.

От принятия auto_ptr в стандарт до нерекомендации Саттером и стандартом кодирования Гугла его использовать и даже (возможно) выкидывания его из 0x прошло всего лет десять.

>В С++ ее можно организовать только с POD-структурами. Все хваленое ООП сразу идет лесом.

В отличие от убогой жабы, в c++ не _всё_ ООП идёт лесом при использовании POD-структур.

>А UnhandledException мы, значит, за падение не считаем?

Нет, это не падение. На практике оно приводит к ошибке 500 если это сервлет или к мату в stderr из цикла обработки сообщений если приложение гуевое. Программа продолжает работать.

>дедлоки (львиная доля которых невозможна при использовании RAII)

Решается механистически - никогда не вызывать сторонний код из критической секции.

>>Судя по тредам вида "когда ж его допилят" я не питаю особого энтузиазма к этому проекту.

>Смотри на это с другой стороны: даже недопиленный он лучше этих ваших эклипсов.

иклипс используется немного почаще.

> Тролли совсем обнаглели: http://img-fotki.yandex.ru/get/3805/legolegs.0/0_15b33_b43d3477_orig

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

> Надоели уже ваши кривые аналогии. gc - это бочка с желе, и точка.

Кривая аналогия -- только у тебя. Равно как и проецирование опыта хеллоуворлдов на весь оставшийся мир.

>Были только софизмы

Какие софизмы? Инструмент имеет высокую цену и ничтожную полезность => инструмент идёт нахрен. Чистейшая логика.

>ООП должно покрывать все аспекты работы с инкапсулированным ресурсом.

Программирование - это труд, а не религия. Если мне нужен класс для работы с xml, сохраняющий документ в файл при своём разрушении я просто возьму обычные класс для xml и положу его в свою обёртку, делающую xmldoc.save() в деструкторе. Делать обёртки для всех методов xmldoc я не буду, просто выставлю его наружу.

>стандартом кодирования Гугла

У них вообще спорный стандарт.

>и даже (возможно) выкидывания его из 0x

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

>Нет, это не падение. На практике оно приводит к ошибке 500

А ты не терял, скажем, на ЛОРе текст поста, когда при отправке случается 500 ошибка?

>Решается механистически - никогда не вызывать сторонний код из критической секции.

Ну а чо, тогда можно вообще ничего в критической секции не делать. Безопаснее же.

>иклипс используется немного почаще.

Матерится тоже.

> В С++ ее можно организовать только с POD-структурами

Раскрой тему. Вообще-то для пула нужен placed new и, возможно, sizeof. Всё. Причем тут POD?

>Инструмент имеет высокую цену и ничтожную полезность => инструмент идёт нахрен.

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

>>ООП должно покрывать все аспекты работы с инкапсулированным ресурсом.

>Программирование - это труд, а не религия. Если мне нужен класс для работы с xml, сохраняющий документ в файл при своём разрушении я просто возьму обычные класс для xml и положу его в свою обёртку, делающую xmldoc.save() в деструкторе. Делать обёртки для всех методов xmldoc я не буду, просто выставлю его наружу.

Сериализация это поточный процесс вообще-то. Если в иерархии есть метод serialize(XmlAppender appender) то тут нужно его вызвать рекурсивно. Или пригласить соответствующий Визитор в корень. Где тут клиент кода имеет дело с самим потоком мне чего-то не понятно.

>Он там остался и даже улучшился (хотя и переименовался

Незыблемый код навека, тащем-то.

>> В С++ ее можно организовать только с POD-структурами

>Раскрой тему. Вообще-то для пула нужен placed new и, возможно, sizeof.

И чтобы конструктор вызванный через placement new все свои ресурсы тоже размещал через placement new. Типичная tailgunner-овская идея о том что если все заранее предусмотреть то можно все сделать зашибись.

>>Нет, это не падение. На практике оно приводит к ошибке 500

>А ты не терял, скажем, на ЛОРе текст поста, когда при отправке случается 500 ошибка?

Я нажимал конпку "Back".

>>Решается механистически - никогда не вызывать сторонний код из критической секции.

>Ну а чо, тогда можно вообще ничего в критической секции не делать. Безопаснее же.

Виляние. Критические секции обычно бывают вида "поставить структуру в очередь на обработку" и "взять структуру из очереди". Куда тут можно привлечь сторонний код я чего-то не понимаю. Но что от плюсофилов видимо можно ждать чего угодно.

>Речь шла о том как управлять памятью - либо мы делаем хорошие средства для ручной работы

Хорошие - это какие? libastral не предлагать. Только программист знает когда объект больше не нужен - ему и решать когда его удалить.

>В С++ не было предложено

Было всё предложено, не упрямствуй. И если gc за ненадобностью не развивается, то автоматические переменные и деструкторы замечательно и предсказуемо работают и как ты не крутись, это факт.

>Сериализация это поточный процесс вообще-то

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

>Если в иерархии

Какой иерархии? У нас тут не жабка, если удобно, то и процедурненько попишем.

>Или пригласить соответствующий Визитор в корень

Кроме как тремя с половиной паттернами мы проектировать не умеем?

>Я нажимал конпку "Back".

Даже если у тебя есть бэкапы на рейде, лентах и перфокартах, это не значит, что исключение не ведёт к потере данных.

>Критические секции обычно бывают вида "поставить структуру в очередь на обработку" и "взять структуру из очереди"

И кто тут ещё гнусно обвинял меня в написании хелловорлдов?

>> Вообще-то для пула нужен placed new и, возможно, sizeof.

> И чтобы конструктор вызванный через placement new все свои ресурсы тоже размещал через placement new

Всего-то? %) Да, нужно, размещать ресурсы тоже через пулы. Какая, блин,.неожиданность. Или вообще делать ресурсы полями самого объекта. Но, прикинь, всё это не имеет отношения к POD. Размещенный в пуле объект будет полноценным Си++-объектом, хоть виртуальное множественное наследование в нем используй.

> Типичная tailgunner-овская идея о том что если все заранее предусмотреть то можно все сделать зашибись.

Да, надо предусматривать многие вещи. И это не моя "идея", это то, чему я научился в том числе и в RT. Когда любимая тобой печать в stderr поломает тебе времянку, ты это поймешь :)

>Да, надо предусматривать многие вещи.

Угу: не забыть открыть клапан фильтра в противогазе, не забыть пристегнуть лыжи, не забыть надёжно привязать гамак, не дай бог забыть о равновесии... Баба? Какая баба? Не до бабы сейчас... =]]]]]]]]]]]

>>Речь шла о том как управлять памятью - либо мы делаем хорошие средства для ручной работы

>Только программист знает когда объект больше не нужен - ему и решать когда его удалить.

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

>И если gc за ненадобностью не развивается,

Конечно не развивается. Его же не прикрутить никак.

>то автоматические переменные и деструкторы замечательно и предсказуемо работают и как ты не крутись, это факт.

Я и не кручусь. Я только что в третий раз доказал несостоятельность RAII и ничего кроме виляния не получил.

>Программисту решать когда и как в конкретной задаче делать сериализацию.

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

>Какой иерархии? У нас тут не жабка, если удобно, то и процедурненько попишем.

Зачем тебе вообще нужен ООП если ты switch-и по меткам типов делаешь?

>>Или пригласить соответствующий Визитор в корень

>Кроме как тремя с половиной паттернами мы проектировать не умеем?

Ну если уж добавлять виртуальные методы извне нельзя как в CLOS, то почему бы не поюзать костыль?

>>Критические секции обычно бывают вида "поставить структуру в очередь на обработку" и "взять структуру из очереди"

>И кто тут ещё гнусно обвинял меня в написании хелловорлдов?

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

>> Да, надо предусматривать многие вещи.

> Угу: не забыть открыть клапан фильтра в противогазе, не забыть пристегнуть лыжи, не забыть надёжно привязать гамак

Главное - не забыть посмотреть на светофор перед тем, как перейти улицу. А то карьера комика может не состояться.

>Главное - не забыть посмотреть на светофор перед тем, как перейти улицу.

Визуальная оценка фактического состояния трафика на дороге и наличия на ней очень шустрых болидов наверно все же важнее.

>Главное - не забыть посмотреть на светофор перед тем, как перейти улицу.

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

> Визуальная оценка фактического состояния трафика на дороге и наличия на ней очень шустрых болидов

Видишь, ты уже понимаешь, что хотя бы кое-что нужно предусматривать.

> С публичными высказываниями только надо быть поосторожнее - могут не так понять =)

Одно дело "не так понять", другое - петросянить. Ты - петросянишь.

> В общем, любви и счастья вам в долгой совместной жизни с С++ ;)

Опять палишься.

>Одно дело "не так понять", другое - петросянить. Ты - петросянишь.

Нормальная реакция, если с другой стороны критицизм отсутствует напрочь...

>Да, нужно, размещать ресурсы тоже через пулы. Какая, блин,.неожиданность.

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

>Размещенный в пуле объект будет полноценным Си++-объектом, хоть виртуальное множественное наследование в нем используй.

Пулы работают на уровне чанков байтов и поэтому про деструкторы ничего не знают.

> Толку от ООП тогда - зеро, если уже рабочий код надо целиком переделывать.

А ты думал, что вот так просто сможешь взять и использовать готовый рабочий не-RT код в RT-приложении? Бгг. Такого даже в RTSJ не будет.

> Пулы работают на уровне чанков байтов и поэтому про деструкторы ничего не знают.

В огороде бузина.

>> Толку от ООП тогда - зеро, если уже рабочий код надо целиком переделывать.

>А ты думал, что вот так просто сможешь взять и использовать готовый рабочий не-RT код в RT-приложении?

Давай какбе без общих слов. Какие конкретно куски кода могут быть железно приклепаны к глобальному распределителю памяти? Зачем им это нужно?

>> Пулы работают на уровне чанков байтов и поэтому про деструкторы ничего не знают.

>В огороде бузина.

Я сразу вижу проблему если она есть. В контексте пула про *тип* удаляемого объекта ничего не известно, поэтому чтобы правильно его удалить, из контекста пула по системной eviction-политике например, придется соорудить трехэтажный хак для которого тоже навскидку нужна динамическая память под маппинг.

>> А ты думал, что вот так просто сможешь взять и использовать готовый рабочий не-RT код в RT-приложении?

> Давай какбе без общих слов.

Видишь ли, я говорю прописные истины для любого, кто работает в области RT. Простенький пример я тебе уже привел - забытый printf может поломать времянку.

> Какие конкретно куски кода могут быть железно приклепаны к глобальному распределителю памяти?

Как звучит настоящий вопрос?

> Я сразу вижу проблему если она есть.

"I see people. Dead people" (c)

> В контексте пула про *тип* удаляемого объекта ничего не известно

Во-первых, это неважно; во-вторых, можно сделать известным.

> поэтому чтобы правильно его удалить, из контекста пула по системной eviction-политике например

Eviction-политика? Системная? Какой бред. Объект из пула удаляется явным вызовом. Пул - это то же, что malloc/free, но для блоков фиксированного размера и гарантированно без обращения к системе.

>> В контексте пула про *тип* удаляемого объекта ничего не известно

>Во-первых, это неважно;

Как это неважно? Если нужно удалить объект размещенный через placement new надо сначала явно вызвать деструктор что нельзя сделать без знания типа объекта. В контексте пула тип неизвестен, есть нетипизированный указатель и размер.

>во-вторых, можно сделать известным.

Сделать виртуальный деутруктор? Тогда придется все наследовать от одного корня.

>Eviction-политика? Системная? Какой бред

Ну лучше централизованно за пулом следить. К примеру, удалить оттуда сразу все по выходу, например, из обработчика. Если там только данные, то для этого надо указателю на вершину пула присвоить указатель на начало пула.

>Объект из пула удаляется явным вызовом. Пул - это то же, что malloc/free, но для блоков фиксированного размера и гарантированно без обращения к системе.

Только надо не забывать о том что объем памяти ограничен и о том что в зависимости от контекста в пул могут помещаться объекты разного типа.

>В контексте пула тип неизвестен

В отсутствие gc нет такого ограничения. Капитан докладывает, что объект удаляется оттуда, где известен его тип. Сначала вызывается деструктор, потом пинается пул. Сборщик мусора собрал твой мозг.

>Капитан докладывает, что объект удаляется оттуда, где известен его тип.

Почитай хоть Александреску "Modern C++ Design", статью о пулах. Нижний уровень про типы ничего не знает.

Почитай что я тебе написал. Не нижний уровень инициирует удаление.

> В контексте пула тип неизвестен, есть нетипизированный указатель и размер.

Еще раз повторяю - зависит от того, как ты сделаешь свой пул. Сделаешь его типизированным (или типизированную обертку вокруг управления нетипизированными блоками памяти) - будешь знать тип.

И кстати, прочти, что написал legolegs.

> Только надо не забывать о том что объем памяти ограничен

Мы ни на секунду об этом не забываем.

> в зависимости от контекста в пул могут помещаться объекты разного типа.

Как сделаешь. Обычно - не могут.