Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Консервативные сборщики мусора это всё разруливают, для этого не нужны никакие макросы и прочие "ManagedObject" (они нужны для точных библиотечных GC).
EP>Смотри например Boehm GC.
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.
Не-не-не-не-не, Девид Блейн. Такой магии нам не надо. Получается, что если случайное 32-битное слово внутри какого-нибуть сжатого блока, хранящегося в памяти, вдруг совпало с адресом внутри другого блока, то второй блок никогда не удалится? Я понимаю, почему этим никто не пользуется. Потому что worst case здесь — это вылетание с OutOfMemoryException, и кастомеру нафиг не впырилось слушать ваши оправдания о крутости сброщика мусора.
EP>Во-первых GC не спасает от утечек. Во-вторых утечка памяти это минорная проблема, особенно по сравнению с утечкой ресурсов (которую на C# получить проще).
В C# просто немного другая парадигма:
1. Там, где реально надо, чтобы оно освободилось, как только стало ненужным, используется IDisposable и using.
2. Во всех остальных случаях достаточно добавить освобождение в финализатор и если чего, вызвать GC.Collect().
EP>Здесь никакого ref-counting и прочего, все значения имеют простой life-time привязанный к scopes — как и >90% всех объектов в программе.
Ага, вот только если я хочу заполнить массив из фонового потока, а потом результат отобразить в GUI, то в C# я добавлю Task.Create() и await и дальше это не моя проблема. А в C++ придется городить огород.
EP>GUI обычно не является какой-то огромной частью кода C++, более того для формочко-ориентированной разработки я именно C# и советовал в соседнем сообщении.
Часто бывают, что формочки переплетены с хитроумной логикой и выбор языка для логики автоматически определяет язык для формочек.
EP>Для C++ в этом случае не нужна никакая генерация кода, в этом реальном примере именно C# показывает свою громоздкость и дорогую поддержку (текстовую кодогенерацию поддерживать сложнее).
Для какого случая? Кто-то зачем-то нагенерил кучу каких-то helper-ов, забив на синтаксический сахар. Скажите мне, какую задачу нагенеренный код решает, и я покажу, как это сделать проще.
EP>EP>auto make_squares(int max)
EP>{
EP> return coroutine<int>::pull_type{[=](auto &yield)
EP> {
EP> for (int i = 0; i < max; i++)
EP> yield(i * i);
EP> }};
EP>}
EP>...
EP>for(auto x : make_squares(10))
EP>{
EP> if(x > 10) break;
EP> cout << x << endl;
EP>}
EP>
О, это красиво. Надо будет взять на учет. Хотя boost немного напрягает монстроидальностью.
EP>Я же говорю, в случае не-БД ближайшем аналогом будет библиотека Range, примерно так:
EP>EP>auto surnames_by_frequency = full_names
EP> | group_by(PROJ(surname))
EP> | view::transform([](const auto &ys)
EP> {
EP> return NEW( (surname, first(ys).surname) (count, distance(ys | view::unique)) );
EP> })
EP> | order_by(PROJ(count));
EP>for(auto x : surnames_by_frequency)
EP> cout << x.surname << " " << x.count << endl;
EP>
"Примерно" потому что у group_by и unique из Range немного другая семантика, но при необходимости можно сделать клон с такой же семантикой.
Тоже довольно неплохо.
Итого: с LINQ и yield Вы меня убедили, но отсутствие нормального GC — все равно большая проблема.
