Здравствуйте, gandjustas, Вы писали:

G>Эта наивная реализация во многих местах осталась и по сей день.
Это проблемы тех мест а не С++ в целом.

И>>Достаточно в таск менеджере взглянуть на кол-во используемой памяти .net прогой и С++ с эквивалентной функциональностью, чтобы понять, что ты гонишь.
G>Покажите две программы на .net и C++ с эквивалнтной функциональностью сложнее HelloWorld, потом посмотрим кто гонит.
G>Кроме того цифра в таск менеждере ни о чем не говорит, просто сверните приложение, будете удивлены.
Ты не в тот таскманагер смотришь, тебе уже сообщали.

G>>>3)Выделение памяти таким алгоритмом создет фрагментацию памяти, то есть остаются блоки невыделенной памяти малых размеров.
И>>Угу, только проблема фрагментации кучи есть и в .net, кстати, как и мемори лики.
G>Доказательства? Опять отправляю вас читать как работает выделение памяти и сборка мусора в .NET.
Кстати, как там на данный момент обстоит дело с GC в условиях наличия за-pin-ованых объектов?

G>Не зачастую, всегда, но GC работает в сотни раз реже, чем выделение-совобождение памяти стандартным аллокатором.
Это как напишешь. В unmanaged в реальном коде где надо performance выделение/освобождение памяти выносят "за скобки" и делают крайне редко.

И>>а) есть стэк;
G>Стек заставляет копировать объекты чаще, чем нужно.
С чего бы вдруг?

И>>b) есть placement new;
G>Теже яйца что и кастомный аллокатор, только сбоку
Только без затрат на выделение памяти. Т.е. совсем бесплатный считай.

И>>c) на мелких объектах свет клином не сошелся — можно и без них обойтись в критичной к скорости части;
G>Я тоже говорю что критичные по скорости вещи надо писать на C, а некритичные, на более высокоуровневых языках. C++ в таком раскладе места нет.
Как показывает практика — есть. В таком контексте С++ от С мало чем отличается, только поудобнее разве что. Не надо только на нём александрескить и говнокодить.