Медленнее работает только при первом запуске, и то на совр. процессорах ты это не заметишь.


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

не, ты не понял, пофиг абсолютно на что API OGL не ОО, вот у тебя в движке есть объект "дерево", есть метод draw и там ты его рисуешь хоть на OGL хоть на DX.
То что API не ОО не заставляет тебя при использовании этого API писать только структурную программу. API OpenGL удобен и без ОО-механизмов.

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

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



Не, это принципиальная штука, освобождением памяти занимается не программист , а системный сборщик мусора. Но вот незадача, программист то точно знает когда память ему не нужна, и при интенсивной работе (new/delete) с памятью все можно сделать идеально. А на платформах типа Java / .NET нельзя принципиально, память зафрагментируется т.е. допустим в идеальном случае данные некого объекта влезают на одну страничку памяти, а при фрагментации памяти эти же данные размажутся на десятке страниц, + там будут данные других объектов, пустые блоки, блоки которые помечены как освобожденные, но еще еще не поджатые сборщиком, каша короче. Это фатально для производительности, будем проигрывать дестятки-сотни процентов в производительности, одни сплошные кэш промахи проца, а если физической памяти не хватит, и включится свап, то это будет вообще звиздец, уже потери будут измерятся многими порядками. Также система сборки мусора может включаться в неподходящиее моменты, получим непредвиденные серьезные провалы производительности.
Добавлено спустя 9 минут, 23 секунды


я не понимаю в чем проблема, вот не отрисовывается у тебя объект "дерево" смотришь там подробнее.

Да код .net работает медленнее, но опять же, не до такой степени, чтобы это действительно было заметно.
На врядли это случится, вроде для управляемого кода память отдельно отводиться.
Иногда можно самому удалять объекты без сборщика мусора.

На самом деле управляемый код работает стабильно и без сбоев, не так часто требуется применять неуправляемый код, а если и требуется, то нужно чтоб это делал человек знающий свое дело, потому как конечно дров можно много наломать и обвинить во всем CLR.
В силу своей работы мне не требуется внедрять в свои программы неуправляемый код, потому что у меня все хорошо работает без него. Но написание игр это конечно отдельная тема.
Добавлено спустя 4 минуты, 39 секунд
в случае с деревом конечно все просто...

Я написал в предыдущеем посте почему современные игры в основном под D3D.

И? В прогу на C++ я напихаю SSE(2)-интринсиков выполняющих fp-вычисления за счет чего прога будет максимально эффективно работать (особенно на современных процах), а как я это сделаю для проги под .Net? Или думаешь транслятор такой умный и сам макимально эффективно соптимайзит огромный fp-код под SSE(2)?

Получается все кто иногда фанатеет в извечных фанатских ветках - это все дети ?

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

Узкие места (вроде сложного нахождения путей, физика, столкновения и т.п.) все же пишутся на С++.

заметно, до десятков процентов разница.
фрагментация "кучи" реальная проблема и на С++, а не теоритическая.
Крупные проекты под Java жрут много памяти и тормозят из-за этого, это не для кого не секрет, хотя там тот же JIT, я пояснил почему это так. В Net та же идеология, только крупных программ я не видел, и примеров не знаю.



Net и Java хороши для определенных областей (средне-мелкие офисные программки) где не требуется жесткий контроль ресурсов и высокая производительность.

неупровляемый код, это костыли, которые разрушают всю красоту идеи.
Добавлено спустя 4 минуты, 44 секунды


компилятор С++ и так при соответтсвующей опции (/arch:SSE2) это все делает. JIT компилятор тоже.