Исходное сообщение
"Результаты анализа системой Coverity безопасности и..." Отправлено VoDA, 26-Фев-12 14:22
> ну вот — чего не хватишься, всё у них запрещают. а почему, > собственно, надо запрещать? Запрещать нужно для запрета совершать ошибки. > или потому, что не способны > даже GC с прогнозируемым временем исполнения написать? Даже на С++ освобождение памяти динамической структуры может занять не прогнозируемое время. Элемент может содержать другой, который содержит список ... и дальше до бесконечности. Потому либо заранее ограничивать типы объектов, следить чтобы другие типа не использовались в RT коде (что упирается в человеческий фактор) либо не применять динамическое выделение памяти вообще. Второй подход позволяет уже в теории убрать часть проблем, что снимает проблему человеческого фактора. А это одна из основных задач развивающих программирование. > вообще, не начинал бы ты про RT. не надо. а то у > меня комплекс неполноценности будет от того, что я однажды вполне себе > использовал для RT Scheme с вполне рабочим GC. и оно таки > было RT. и даже работало без проблем. а оказывается, так нельзя… Я уже приводил примеры RT приложений на pure-java. Причем даже на базовом GC от HotSpot, а не на G1. Так что можно писать RT приложения с GC, но в массовом производстве грамотнее применять иные подходы.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> ну вот — чего не хватишься, всё у них запрещают. а почему, >> собственно, надо запрещать? > Запрещать нужно для запрета совершать ошибки. >> или потому, что не способны >> даже GC с прогнозируемым временем исполнения написать? > Даже на С++ освобождение памяти динамической структуры может занять не прогнозируемое время. > Элемент может содержать другой, который содержит список ... и дальше до > бесконечности. Потому либо заранее ограничивать типы объектов, следить чтобы другие типа > не использовались в RT коде (что упирается в человеческий фактор) либо > не применять динамическое выделение памяти вообще. > Второй подход позволяет уже в теории убрать часть проблем, что снимает проблему > человеческого фактора. А это одна из основных задач развивающих программирование. >> вообще, не начинал бы ты про RT. не надо. а то у >> меня комплекс неполноценности будет от того, что я однажды вполне себе >> использовал для RT Scheme с вполне рабочим GC. и оно таки >> было RT. и даже работало без проблем. а оказывается, так нельзя… > Я уже приводил примеры RT приложений на pure-java. Причем даже на базовом > GC от HotSpot, а не на G1. Так что можно писать > RT приложения с GC, но в массовом производстве грамотнее применять иные > подходы.
	Введите код, изображенный на картинке: