VD>>>XNA вроде как тоже в применении в разы проще чем DirectX. Не так ли? C>>И много Half-life'ов на XNA написано? VD>Дык он только появился. Уверен, что напишут и не один. Новые команды могут догнать старые только выбирая более мощьные и удобные инструменты. XNA — это шанс войти на рынок.
Не встревая в основную дискуссию: XNA as-is, к сожалению, суть рекламная поделка. Ничего +- существенного на нем написать нельзя. Может быть в будущем это и измениться, но пока так.
Сама проблема управления памятью, конкретно для игр — как правило не стоит в классическом виде, ибо подавляющая часть ресурсов выделяется статически либо 1 раз (читать — мы точно знаем когда, сколько и каких ресурсов нам понадобится. И точно знаем когда, где и как мы их убьем). Было бы интересно посмотреть на движок, полностью живущий в управляемой среде (а не затащенный в нее через врапперы) — но пока я такого не видел и не очень понимаю какие бонусы "именно для движка" это может принести — судя по тому что такого нет — не только я.
А для написания говнокода, которого 80% в любом проекте, там да — почему нет, такие примеры есть и вполне успешные.
Здравствуйте, VladD2, Вы писали:
VD>>>С чего бы это? Я вот видел код игровых движков и что-то особых проблем там не заметил. C>>Ну так естественно — указатели с подсчетом ссылок, и проблем нет. VD>О чем ты?
В играх очень важно, чтобы движек работал предсказуемо. Там обычно дофига всяких кэшей, и никому не хочется, чтобы кэшировалось что-то лишнее.
Ну и еще приставки есть, где память — совсем даже ценный ресурс (на Wii ее всего около 64Мб, например).
C>>И много Half-life'ов на XNA написано? VD>Дык он только появился. Уверен, что напишут и не один. Новые команды могут догнать старые только выбирая более мощьные и удобные инструменты. XNA — это шанс войти на рынок.
Так никто не спорит — для определенных типов игр он вполне подходит.
VD>XNA — это шанс войти на рынок.
И в догонку, конкретно по этой фразе: геймдев он гораздо ближе к медиа, нежели к it. Программирование — хорошо если четверть проекта.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Nebula или Ogre тоже в разы проще в применении чем DirectX.
VD>DirectX — это АПИ, а Ogre — игровой движок. Их просто сравнивать нельзя. Ты лучше сравни игровой код для Ogre и менеджед-Ogre (если я не ошибаюсь он есть в двух вариантах).
Можно, так как XNA тоже высокоуровневая надстройка. Хотя с небулой или огром сравнивать не стоит скорее счем то попроще типа Irrlicht
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>То есть у тея самого никогда не было чтобы программа подвешивала систему из-за нехватки GDI ресурсов, или уходила в синий экран при работе c DX?
VD>А причем тут это? Ты вот видел менеджед-программу которая делала бы это?
А ты видел не менеджед delphi программу которая бы это делала?
VD>Чтобы терять необходимое для появления дыр в окнах количество ресурсов их нужно в цикле складывать в список. Иначе схема слежения за хэндлами их подчистит. Так что тут как раз в управляемом мире все очень хорошо. Схему слежения за ресурсами продумали создатели фрэймворка. Причем они же обеспечили подстраховку. Так что написать код который достигает описанных тобой эффектов на управляемом языке куда сложнее чем на С++.
Если на C++ пишешь использую любой высокоуровневый фреймворк то никаких отличий.
Re[7]: Сборщик мусора и размещение объектов в стеке
Здравствуйте, Константин Л., Вы писали:
КЛ>А ты возьми за правило, что деструкторы не должны кидать исключений. И вообще, пост твой не в тему.
А ты думашь, что писать на языке где нужно то и дело лезть в спеку и к тому же нужно знать море мелких правил из серии "как не пройти по коридору не наступив на грабли..." позволяет быстро писать надежный код?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, doarn, Вы писали:
VD>>XNA — это шанс войти на рынок. D>И в догонку, конкретно по этой фразе: геймдев он гораздо ближе к медиа, нежели к it. Программирование — хорошо если четверть проекта.
Наверно так и есть. И XNA, кстати, насклько мне известно, как раз не просто либа для 3Д, а комплексное решение. См. XNA Studio.
Ну, а насколько он готов к применению не мне судить. Думаю, раз уж МС занялся, то рано или поздно до ума доведут.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>А ты видел не менеджед delphi программу которая бы это делала?
Мы о Дельфи или о управляемом коде?
FR>Если на C++ пишешь использую любой высокоуровневый фреймворк то никаких отличий.
Ну, ну. Вот тут еао197 жаловался как-то на то, что в одном проекте приходится увязвать разные библиотеки которые получаются совместимы как уж с ежом только потому, что там были приняты разные политики управления память.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
FR>>А ты видел не менеджед delphi программу которая бы это делала?
VD>Мы о Дельфи или о управляемом коде?
Мы о том что для типовых случаев управление и ресурсами и памятью тривиально и не зависит от того управляемый фреймворк или нет.
FR>>Если на C++ пишешь использую любой высокоуровневый фреймворк то никаких отличий.
VD>Ну, ну. Вот тут еао197 жаловался как-то на то, что в одном проекте приходится увязвать разные библиотеки которые получаются совместимы как уж с ежом только потому, что там были приняты разные политики управления память.
Здравствуйте, VladD2, Вы писали:
VD>Факт в том, что в сложной программе, если конечно она должна сносно работать и не течь, дожена быть продумана и отслежена концепция вледения памятью. Это дополнительный слой головной боли.
В сложной программе дожена быть продумана и отслежена концепция управления самыми разными ресурсами — память всего лишь один из них.
Имея GC становится одного гемора поменьше, но остаётся ещё куча других ресурсов, которые надо освобождать вовремя. Если класс реализует IDisposable, то об этом надо думать обязательно, причём иногда надо знать как именно он реализован — я как-то нарывался на вещи неочевидные.
Я не к тому, что ты это не знаешь, а к тому, что в спорах ручное управление пмятью против GC очень часто передёргивают. В .NET можно тоже нехило косячитm несмотря на GC.
now playing: Scorn — Glugged
Re[8]: Сборщик мусора и размещение объектов в стеке
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
КЛ>>А ты возьми за правило, что деструкторы не должны кидать исключений. И вообще, пост твой не в тему.
VD>А ты думашь, что писать на языке где нужно то и дело лезть в спеку и к тому же нужно знать море мелких правил из серии "как не пройти по коридору не наступив на грабли..." позволяет быстро писать надежный код?
Не думаю. Думаю, что чем тоньше стандарт, тем лучше (в ветке .NET я не давно высказался про то, что скоро без стандарта c# проги писать будет затруднительно). Однако с++ эта беда не обошла стороной и это факт. Стандарт ужасно большой и сложный. Однако я за все время коммерческой разработки на нем (~2,5 года) заглядывал в стандарт разы. Со временем он нужен все меньше и меньше.
btw, в практически любом языке есть куча мелких best practices и правил. Просто их несоблюдения для с++ заканчивается AV, а для других исключениями.
Здравствуйте, EvilChild, Вы писали:
EC>В сложной программе дожена быть продумана и отслежена концепция управления самыми разными ресурсами
+1
EC> — память всего лишь один из них.
А вот тут не совсем.
1. Памятью можно управлять автоматически.
2. Без автоматического управления память превращается в огромную проблему.
EC>Имея GC становится одного гемора поменьше, но остаётся ещё куча других ресурсов, которые надо освобождать вовремя.
Не так их много как кажется. Многие ресурсы достаточно прибивать в финализаторах. Остаются только блокирующие ресурсы. Вот их нужно отслеживать, но их обычно не много.
EC> Если класс реализует IDisposable, то об этом надо думать обязательно, причём иногда надо знать как именно он реализован — я как-то нарывался на вещи неочевидные.
Это не совсем так. В большинстве случаев все будет работать корректно даже если ты наплюешь на IDisposable. Например, формы тоже реализуют IDisposable, на на них можно забить. Если не забьешь, то будет немного лучше, но не сильно. Проблем точно не будет.
EC>Я не к тому, что ты это не знаешь, а к тому, что в спорах ручное управление пмятью против GC очень часто передёргивают. В .NET можно тоже нехило косячитm несмотря на GC.
Накосячить можно везде. Вопрос не в этом. Просто когда у тебя постоянно весит проблема управления памятью, то ты должен все время верять с ней все свои решения. Это требует постоянных умственных усилий. То что некоторые орлы тратят эти усилия незаметно для себя ровным счетом ничего не значит. Они просто привыкли трать часть своего времени впусую.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
VD>>Мы о Дельфи или о управляемом коде?
FR>Мы о том что для типовых случаев управление и ресурсами и памятью тривиально и не зависит от того управляемый фреймворк или нет.
Это заблуждение. И пример с Дельфи это хорошо демонстриурет. В дотнете разработан алгоритм отслеживания ресурсов. Даже если писать код крайне халтурно (без юсингов) с GDI-ресурсами особых проблем не будет. Максимум чего ты добьешся — это потеряешь в производительности. В Дельфи же потеря ресурсов будет приводить к неработоспособности приложения, а то и ОС.
FR>>>Если на C++ пишешь использую любой высокоуровневый фреймворк то никаких отличий.
VD>>Ну, ну. Вот тут еао197 жаловался как-то на то, что в одном проекте приходится увязвать разные библиотеки которые получаются совместимы как уж с ежом только потому, что там были приняты разные политики управления память.
FR>Угу "а у вас зато негров линчуют"
У нас негры давно кончились.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Сборщик мусора и размещение объектов в стеке
Здравствуйте, Константин Л., Вы писали:
КЛ>Не думаю. Думаю, что чем тоньше стандарт, тем лучше (в ветке .NET я не давно высказался про то, что скоро без стандарта c# проги писать будет затруднительно).
Ты неверно оценивашь ситуацию. То что в Шарпе появились косяки — это конечно прискорбно. Но до кривости С++ Шарпу еще очень далеко. Думаю, он никогда этого не осилит.
КЛ> Однако с++ эта беда не обошла стороной и это факт. Стандарт ужасно большой и сложный. Однако я за все время коммерческой разработки на нем (~2,5 года) заглядывал в стандарт разы. Со временем он нужен все меньше и меньше.
В С++ очень часто приходится сверяться со стандартом. Там нелогичных решений море. Одни только невертуальные вызовы виртуальных деструкторов чего стоят? Но проблема С++ даже не в сложности стандрата. Он все же не так сложен. Проблем в этом языке две:
1. Стандарт очень многое неоговаривает или оговаривает в стиле "Если сделать А, то будет UB".
2. В языке нет примитивов для решения частовтречающихся задач, вроде передаче ссылки на методы.
КЛ>btw, в практически любом языке есть куча мелких best practices и правил. Просто их несоблюдения для с++ заканчивается AV, а для других исключениями.
Не, не. Тут речь не о best practices, а о шаманстве. Сюда не ходы, туда ходы. А то снег башка попадет совсем мертвый будешь. (с)
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Сборщик мусора и размещение объектов в стеке
Здравствуйте, PC Car, Вы писали:
PC>А что будет, если из кода внутри юзинга вылетит исключение? Которое по идее ловится на два уровня выше по колстеку?
Ресурсы освободятся, а исключение полетит выше по стеку вызовов и будет отловено на два уровня выше, но ресурс к тому времени будет уже освобожден.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Схему слежения за ресурсами продумали создатели фрэймворка.
ОС проектировалось задолго до .NET, и тогда про такое не подумали. GDI хендлы хранятся в глобальной таблице ядра, которая одна на сессию (считай — на все процессы). Один процесс никогда не сможет создать все возможные 16К хендлов — от этого есть защита (в ядре). Но 2 процесса это могут сделать очень легко. Фреймворк, видимо, должен иметь компонент в ядре, что бы за этим следить. То есть это либо решено только в новых ОС, либо не решено нигде.
P.S. BSOD при использовании DX — однозначно баг ОС либо видеодравера.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
GN>ОС проектировалось задолго до .NET, и тогда про такое не подумали. GDI хендлы хранятся в глобальной таблице ядра, которая одна на сессию (считай — на все процессы). Один процесс никогда не сможет создать все возможные 16К хендлов — от этого есть защита (в ядре). Но 2 процесса это могут сделать очень легко. Фреймворк, видимо, должен иметь компонент в ядре, что бы за этим следить. То есть это либо решено только в новых ОС, либо не решено нигде.
Во фрэймворке сделано слежение за утеряными хэндлами. При создании хэндла он помещается в специльную обетрку. Если произходят проблемы с хэндлами, то запускается сборка мусора которая высвобождает утерянные хэндлы. Это позволяет программисту тупо не брость ненужные ресурсы, а фрэйворк их сам освободит. В отличии от файлов ГДИ-ресурсы ничего не блокируют (в NT), так что пока их достаточно проблем нет. Ну, а если их недостаточно, то сбркра мусора вернет все потерянные ресурсы.
GN>P.S. BSOD при использовании DX — однозначно баг ОС либо видеодравера.
+1
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
.
