C/C++? Закапывайте

> Это объясняется тем, что развенчивается миф о большой потере производительности по причине автоматического управления памятью

Это типа перевод фразы "The chance of running into all kinds of memory problems is gradually outweighing the performance penalty you have to pay for garbage collection"? Тогда поздравляем вас, гражданини, соврамши.

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

а я тут подумал, уместен ли вообще сборщик мусора в ядре? Например, когда ядру не хватает свободной памяти, оно может сбросить буферы с кэшем ну или выгружает страницы в своп. Т.о. в любом случае накладные расходы на управление памятью присутствуют. Что если в подходящих местах заодно с прочими заданиями, освобождать мёртвые блоки памяти? Что вы думаете по этому поводу?

Мне кажется, что включение GC в ядра современных ОС всего лишь вопрос времени. Ручное освобождение памяти на столько же архаично и неактуально, как и пересчет адресов смещений символов модуля вручную. И чем скорее это поймут программисты, тем лучше будет для всех.

> Мне кажется, что включение GC в ядра современных ОС всего лишь вопрос времени. Ручное освобождение памяти на столько же архаично и неактуально, как и пересчет адресов смещений символов модуля вручную

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

>Дебилушко, откуда йадро знает - является ли тот или иной кусок памяти, распределенной приложению, гарбиджем?

имелось ввиду, что в ядре находится ядровый GC который убирает за ядром, что еще больший полярный зверек.

> Ручное освобождение памяти на столько же архаично и неактуально, как и пересчет адресов смещений символов модуля вручную.

Я Вас совсем не понимаю. Современное ядро вообще чтоли не должно иметь кода менеджера памяти (хорошо, если бы она была такой плоской и красивой, как в userspace ;])?

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

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

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

С++ могут потихоньку вытеснять с рынка desktop applications, но очень потихоньку.

Выгоняйте индусов.

Глупый ананимус? Закапывайте!

wtf is ddj?

Топик стартеру срочно рекомендуется купить мозг. А то недоразумение которое у него сейчас вместо этого органа рекомендуется закопать.

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

>С++ могут потихоньку вытеснять с рынка desktop applications, но очень потихоньку.

А в чем бред то? Ключевое слово fashion, т.е. мода. Ну он и говорит, что толпы леммингов уйдут с языков где нет gc, в частности с C/C++, на что-нибудь еще.

Толпы леммингов С++ никогда не использовали. Они использовали Delphi, Visual Basic, C#, Java (впрочем эти языки использовали и профессионалы). С++ слишком часто стреляет в ногу.

А GC это не так важно, лемминги насрут везде, GC не панацея.

anonymous, 
forget this f..%in modern soft,
the time has come for you to leave the mortal croft,
all your dreams will beats into dust,
die, die, die you must