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

EP>>Консервативные сборщики мусора это всё разруливают
AVK>Консервативные сборщики имеют очень печальную производительность.

Я знаю о их проблемах, тем не менее:
а) им не нужны никакие специальные макросы и подобное
б) имеют область применения
в) это ещё вопрос что производителей — быстрый C++ с медленным GC, или медленный C# с быстрым GC.

B>>>Если это не делать постоянно, то потом будете полдня отлавливать memory leaks в дебаггере.
EP>>Во-первых GC не спасает от утечек.
AVK>Смотря что понимать под утечками.

Ну конечно же тебе ближе определение где утечка на C++ это УТЕЧКА, а утечка на C# это вообще никакая не утечка, а даже фича такая

EP>> Во-вторых утечка памяти это минорная проблема, особенно по сравнению с утечкой ресурсов (которую на C# получить проще).
AVK>Тут видишь какое дело — подтекающий или страдающий уявзимостями типа переполнения буфера плюсовый софт попадается постоянно, а вот со страдающим утечками ресурсов дотнетный софт я пока не встречал. Не скажешь почему?

Без понятия, может избирательная память такая, а может особенности кругозора
Да и при чём тут переполнение буфера? Это во-первых проблема скорее свойственная C коду, а во-вторых речь шла про утечки

EP>>Я же говорю, в случае не-БД ближайшем аналогом будет библиотека Range, примерно так:
EP>>[ccode]
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));
AVK>Макросы, да?

В PROJ аналогичная лямбда возвращающая соответствующее поле аргумента. Лямбды на C# лаконичней, да, (нет return и т.п.) о чём я неоднократно писал.
В NEW эмуляция анонимных типов, можно без неё — тогда внутри лямбды transfrom объявляется обычная структура, сразу же заполняется и возвращается — лишние несколько строчек.

AVK>Что ты там про текстовую кодогенерацию только что написал?

Мне цитату привести?