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

EP>>Консервативные сборщики мусора это всё разруливают, для этого не нужны никакие макросы и прочие "ManagedObject" (они нужны для точных библиотечных GC).
EP>>Смотри например Boehm GC.
B>

it must scan parts of storage (most notably the execution stack) where there are words of storage that MIGHT be an object address and make the CONSERVATIVE assumption that if it looks like a valid address, and there is an object that has that address, then the object should not be collected.

B>Не-не-не-не-не, Девид Блейн.

Я сразу сказал про консервативность.

B>Такой магии нам не надо. Получается, что если случайное 32-битное слово внутри какого-нибуть сжатого блока, хранящегося в памяти, вдруг совпало с адресом внутри другого блока, то второй блок никогда не удалится?

Да. Но есть механизмы для информирования GC что вот в этом большом массиве нет никаких указателей — это снижает вероятность такого события. В том числе такой интерфейс даже стандартизировали в C++11 — std::declare_no_pointers.

B>Я понимаю, почему этим никто не пользуется. Потому что worst case здесь — это вылетание с OutOfMemoryException, и кастомеру нафиг не впырилось слушать ваши оправдания о крутости сброщика мусора.

Такой worst case крайне маловероятен. Например у хэш-таблиц линейный худший случай, что приводит к вырождению многих алгоритмов в квадратичные — тем не менее хэш таблицы используются повсеместно, потому что такой исход маловероятен.
Основные проблемы консервативных GC от того что трудно перемещать объекты по памяти, так как неизвестно какие ссылки на эти объекты можно обновлять, а какие нет (потому что это на самом деле не ссылки, а какие-то данные).

EP>>Во-первых GC не спасает от утечек. Во-вторых утечка памяти это минорная проблема, особенно по сравнению с утечкой ресурсов (которую на C# получить проще).
B>В C# просто немного другая парадигма:
B>1. Там, где реально надо, чтобы оно освободилось, как только стало ненужным, используется IDisposable и using.

using это лишь полумера. Например при добавлении ресурса в один из классов, все классы напрямую или косвенно его использующие сами становятся ресурсами, транзитивно — и нужно по всей цепочке делать Dispose, и во всех местах использования ставить using — локальное изменение влечёт цепочку глобальных. В Nemerle ЕМНИП это как-то пытались улучшить через AutoDispose.

EP>>Здесь никакого ref-counting и прочего, все значения имеют простой life-time привязанный к scopes — как и >90% всех объектов в программе.
B>Ага, вот только если я хочу заполнить массив из фонового потока, а потом результат отобразить в GUI, то в C# я добавлю Task.Create() и await и дальше это не моя проблема. А в C++ придется городить огород.

Await реализуется на тех же механизмах что и yield. Даже отсутствие await конкретно в этом примере погоды не делает — будет просто явный .then с одной лямбдой.

EP>>GUI обычно не является какой-то огромной частью кода C++, более того для формочко-ориентированной разработки я именно C# и советовал в соседнем сообщении.
B>Часто бывают, что формочки переплетены с хитроумной логикой и выбор языка для логики автоматически определяет язык для формочек.

Бывает, несомненно. А бывает что эту хитроумную логику можно разрулить декларативно, с помощью соответствующего DSL.
А что часто, а что нет — ещё вопрос, ибо много типовых задач — отсюда и появляются Access'ы, LightSwitch'и и прочие 1С-ы.