Здравствуйте, Cyberax.

Давай перейдем к фактам:
Proposal: Transparent Garbage Collection for C++ (N1833).
Так скорее всего и будет в C++0x (с некоторыми незначительными измениями наверно).

Все-таки мне не очень понятно как будут подсчитываться gc roots, и какой overhead будет.
Стандарт как обычно скажет implementation-defined.

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

>> Ок. Опционально потенциальная утечка памяти
C>Согласен.
Смотрим по ссылке выше и видим — утечки по умолчанию нет
Еще не нравится в proposalе, что new T — может быть как garbage collected pointer, так и нет, также есть new(nogc) T, но нет new(gc) T. И то, что нет pragmы для такого поведения — по-умолчанию gc не нужен (new T), но когда явно напишу new(gc) T он сработает. Тоже самое про malloc. И то, что finalizable надо регистрировать.

>> Кстати с этим опциональным GC будет очень интересная ситуация — уже есть
>> existing practice в виде C++/CLI
C>Я думаю, за основу возьмут консервативную сборку мусора. Точная сборка
C>тянет за собой слишком много всего.
Да. Интересно будет выглядеть новая ревизия C++/CLI, основанная на C++0x

>> но в таком виде как он в C++/CLI его добавлять нельзя — в основном
>> из-за ограничений, наложенных самим CLI (например hydebysig, другой
>> lookup и.т.д.)
C>На самом деле, если рассматривать байт-код CLR просто как целевую
C>платформу для компиляции, то можно сравнительно нормально реализовать
C>всю семантику С++. Проблемы начинаются при попытке сделать С++
C>безопасным и интероперабельным с остальным .NET
+1

C>Я как-то прикидывал ради интереса что нужно добавить в С++ для поддержки
C>точной сборки — получалось не сильно много всего.
Для точной по-моему лучше чем как в C++/CLI не сделать... Т.е. ^ % pinning gcnew ref и.т.д.
Может от ref получиться отказаться.

>> стоять трудная задача — или добавить то, что уже продумали, но будет
>> абсолютно не логично для С++ users, или самим что-то придумывать, что не
>> будет совместимо с C++/CLI, и тогда C++0x скорее всего лишь будет еще
>> одним стандартным диалектом языка C++, который Microsoft по-любому не
>> будет поддерживать...
C>У меня такое подозрение, что GC в С++ ждет судьба фичи "export template".
Сложно сказать. Плохо лишь то, что деструкторы вызываться не будут.
Впрочем это наверно от моего непонимания GC

>> Да и вообще этот GC не сильно нужен в таком языке как C++, ИМХО это
>> просчет Bjarne Stroustrup.
C>GC бывает все же нужен в задачах по обработке сложных структур данных,
C>где сложно выделить политики владения (например, в достаточно сложных
C>компиляторах).
ИМХО остальные 99% userов будут использовать GC как стандартный memory leak detector.

>> З.Ы. А нам-то всего лишь надо move semantics, auto и concepts... и threads
C>Еще бы reflection (compile-time) хотелось бы. И метакод, работающий на
C>уровне методов (а не только типов).
Ну да И это тоже. И template variable arguments.

Pavel Chikulaev wrote:
> Давай перейдем к фактам:
> Proposal: Transparent Garbage Collection for C++ (N1833)
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1833.pdf&gt;.
Transparent — это теперь новое название консервативного GC

В статье, кстати, есть тонкие моменты. Например, это выражение неверно:

There are no correctness restrictions on, for example, the life-time
of C++ references to garbage-collected memory.

Консервативный GC требует атомарности операций над указателями. На
практике это обычно не представляет проблем (хотя они все же бывают), но
это все же должно быть прописано в Стандарте.

> Так скорее всего и будет в C++0x (с некоторыми незначительными измениями
> наверно).
Не впечатляет, честно говоря.

> Все-таки мне не очень понятно как будут подсчитываться gc roots, и какой
> overhead будет.
С этим все достаточно просто — сканируется стек, регистры, куча и
статические данные. Overhead можно посмотреть по Boehm GC — это
фактически уже близкая к идеальной реализация консервативного сборщика.

> И то, что нет pragmы для такого поведения — по-умолчанию gc не нужен
> (new T), но когда явно напишу new(gc) T он сработает. Тоже самое про
> malloc. И то, что finalizable надо регистрировать.
Это явно поправят.

> C>Я как-то прикидывал ради интереса что нужно добавить в С++ для поддержки
> C>точной сборки — получалось не сильно много всего.
> Для точной по-моему лучше чем как в C++/CLI не сделать... Т.е. ^ %
> pinning gcnew ref и.т.д.
Крыжечки и процентики не нужны — они заменяются специальными типами
умных указателей (как и pinning). При разыменовании указателя должна
возвращаться "умная ссылка"

> Может от ref получиться отказаться.
Нет, ее лучше оставить. Хотя я бы предпочел что-нибудь типа атрибута
"mapped", означающего, что для класса генерируется информация для GC (и
runtime-reflection'а).

Типа так:

mapped class SomeClazz
{
    gc_ptr<SomeClazz> next;
    weak_ptr<SomeClazz> some;
    phantom_ptr<SomeClazz> phantom;
    
    const char *str;
    std::vector<Something*> will_not_be_scanned;
};

Финализаторы вполне логично добавляются так:

mapped class SomeClazz : public virtual finalizable
{
...
};

Где finalizable задается примерно так:

class finalizable
{
    virtual void finalize(){delete this;};
};

Соответственно, код вызова финализации в GC можно представить так:

auto finish_him=dynamic_cast<gc_ptr<finalizable>>(obj);
if (finish_him) finish_him->finalize();

(в реальной жизни оптимизируется еще во время компиляции). При этом
сохраняется нормальная семантика деструкторов С++.

> C>У меня такое подозрение, что GC в С++ ждет судьба фичи "export template".
> Сложно сказать. Плохо лишь то, что деструкторы вызываться не будут.
> Впрочем это наверно от моего непонимания GC
Деструкторы в принципе не живут вместе с GC.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>c-smile wrote:
>> CS>>Интересно а как осущесвляется этот самый AIO без встроенных threads?
>> C>А зачем они для асинхронного ввода/вывода нужны? Смотри http://asio.sf.net
>> Для асинхронного нужны — без них никак.
C>Уверены? Посмотрите паттерн Proactor —
C>http://www.cs.wustl.edu/~schmidt/PDF/proactor.pdf
C>Он поддерживает многотредовость, но не требует ее.

completion ports есть не на всех платформах т.е. generic
implementation должна включать потоки и синхронизационные
примитивы в generic исполнении для всех платформ.
Более того — потоки то есть не везде.

>> См. например:
>> http://asio.sourceforge.net/boost-asio-proposal-0.3.6/boost/asio/detail/mutex.hpp
C>То что там есть поддержка тредов — не значит, что без них работать нельзя.

В общем случае нельзя.
"C++ VM" не включает в себя синхронизационные атомарные примитивы и потоки.
Соответсвенно только средствами C++ как платформы это решить нельзя.
И это хорошо.

>> CS>>Т.е. tr2 должен иметь treads еще от boost.
>> CS>>no way in C++.
>> C>Boost.Threads тоже пойдет в TR2.
>> А дальше чего будет?
C>После TR2 будет обсуждение и включение в Стандарт.

Ага, ну значит никогда ибо сначала оно должно пройти в
boost, потом в tr2 а потом уже в финал. Не в этой жизни, короче.

c-smile wrote:
> C>Уверены? Посмотрите паттерн Proactor —
> C>http://www.cs.wustl.edu/~schmidt/PDF/proactor.pdf
> C>Он поддерживает многотредовость, но не требует ее.
> completion ports есть не на всех платформах
На остальных (реально имеющих значение) есть /dev/poll, kpoll и т.п.

> implementation должна включать потоки и синхронизационные
> примитивы в generic исполнении для всех платформ.
> Более того — потоки то есть не везде.
А там где нет — просто и не делать AIO.

> http://asio.sourceforge.net/boost-asio-proposal-0.3.6/boost/asio/detail/mutex.hpp
> C>То что там есть поддержка тредов — не значит, что без них работать нельзя.
> В общем случае нельзя.
> "C++ VM" не включает в себя синхронизационные атомарные примитивы и потоки.
Скоро будет. В виде стандартной библиотеки и немного более тщательнее
определенной модели памяти.

>> > C>Boost.Threads тоже пойдет в TR2.
>> > А дальше чего будет?
> C>После TR2 будет обсуждение и включение в Стандарт.
> Ага, ну значит никогда ибо сначала оно должно пройти в
> boost, потом в tr2 а потом уже в финал. Не в этой жизни, короче.
В Boost'е оно уже есть (сейчас последняя неделя review), в TR2 тоже явно
будет (в комитете понимают, что сетевая библиотека очень нужна).

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Transparent — это теперь новое название консервативного GC
Partially conservative

>> Так скорее всего и будет в C++0x (с некоторыми незначительными измениями
>> наверно).
C>Не впечатляет, честно говоря.
Что именно не нравиться?

>> И то, что нет pragmы для такого поведения — по-умолчанию gc не нужен
>> (new T), но когда явно напишу new(gc) T он сработает. Тоже самое про
>> malloc. И то, что finalizable надо регистрировать.
C>Это явно поправят.
Что регистрировать надо или то, что меня не устраивает?

C>Крыжечки и процентики не нужны — они заменяются специальными типами
C>умных указателей (как и pinning). При разыменовании указателя должна
C>возвращаться "умная ссылка"
Еще один повод разрешить переопределять operator .

>> Может от ref получиться отказаться.
C>Нет, ее лучше оставить. Хотя я бы предпочел что-нибудь типа атрибута
C>"mapped", означающего, что для класса генерируется информация для GC (и
C>runtime-reflection'а).
Пусть native-speakers выбирут лучшее название

C>Финализаторы вполне логично добавляются так:
C>

C>mapped class SomeClazz : public virtual finalizable
C>{
C>...
C>};
C>

Лучше автоматически, а-ля ~T из С++/CLI.

>> C>У меня такое подозрение, что GC в С++ ждет судьба фичи "export template".
>> Сложно сказать. Плохо лишь то, что деструкторы вызываться не будут.
>> Впрочем это наверно от моего непонимания GC
C>Деструкторы в принципе не живут вместе с GC.
Знаю Можно было бы автоматически генерировать finalize, убрав delete объектов,
и вызов деструкторов базовых классов и членов.

Pavel Chikulaev wrote:
> C>Transparent — это теперь новое название консервативного GC
> Partially conservative
Это примерно как "немного беременна"

>> > Так скорее всего и будет в C++0x (с некоторыми незначительными измениями
>> > наверно).
> C>Не впечатляет, честно говоря.
> Что именно не нравиться?
Не вижу смысла в этом.

>> > И то, что нет pragmы для такого поведения — по-умолчанию gc не нужен
>> > (new T), но когда явно напишу new(gc) T он сработает. Тоже самое про
>> > malloc. И то, что finalizable надо регистрировать.
> C>Это явно поправят.
> Что регистрировать надо или то, что меня не устраивает?
Семантику вызовов new.

> C>Крыжечки и процентики не нужны — они заменяются специальными типами
> C>умных указателей (как и pinning). При разыменовании указателя должна
> C>возвращаться "умная ссылка"
> Еще один повод разрешить переопределять operator .
Давно пора бы.

> C>Нет, ее лучше оставить. Хотя я бы предпочел что-нибудь типа атрибута
> C>"mapped", означающего, что для класса генерируется информация для GC (и
> C>runtime-reflection'а).
> Пусть native-speakers выбирут лучшее название
Согласен, хотя это непринципиально.

> C>mapped class SomeClazz : public virtual finalizable
> C>{
> C>...
> C>};
> C>
> Лучше автоматически, а-ля ~T из С++/CLI.
Нет уж. В моем дизайне mapped-класс может быть распределен обычным не-gc
оператором new или создан на стеке, при этом семантика деструкторов
остается та же. А вот финализация будет использоваться только совместно
с GC.

Более того, в моем дизайне для работы STL с GC фактически надо всего
лишь убрать из Стандарта пункт 20.1.5.4:

— The typedef members pointer, const_pointer, size_type, and
difference_type are required to be T*,T const*, size_t, and ptrdiff_t,
respectively.

Точнее, этот пункт надо изменить, чтобы можно было использовать умные
указатели.

>> > Сложно сказать. Плохо лишь то, что деструкторы вызываться не будут.
>> > Впрочем это наверно от моего непонимания GC
> C>Деструкторы в принципе не живут вместе с GC.
> Знаю Можно было бы автоматически генерировать finalize, убрав delete
> объектов, и вызов деструкторов базовых классов и членов.
Тоже не надо. Финализатор — это все же совсем другая сущность (вспомним
твой пример с C++/CLI), так что лучше его не смешивать с деструкторами.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

?>> > Так скорее всего и будет в C++0x (с некоторыми незначительными измениями
>>> > наверно).
>> C>Не впечатляет, честно говоря.
>> Что именно не нравиться?
C>Не вижу смысла в этом.
Ну ты недавно лишь говорил, что GC иногда нужен...


>> C>Крыжечки и процентики не нужны — они заменяются специальными типами
>> C>умных указателей (как и pinning). При разыменовании указателя должна
>> C>возвращаться "умная ссылка"
>> Еще один повод разрешить переопределять operator .
C>Давно пора бы.
Эх. Ну почему его нет в C++98 (

>> C>mapped class SomeClazz : public virtual finalizable
>> C>{
>> C>...
>> C>};
>> C>
>> Лучше автоматически, а-ля ~T из С++/CLI.
C>Нет уж. В моем дизайне mapped-класс может быть распределен обычным не-gc
C>оператором new или создан на стеке, при этом семантика деструкторов
C>остается та же. А вот финализация будет использоваться только совместно
C>с GC.
Тоже самое. Если создание с помощью new — не использовать ~T,
с помощью new(gc) или лучше gcnew — тогда использовать ~T.

C>Более того, в моем дизайне для работы STL с GC фактически надо всего
C>лишь убрать из Стандарта пункт 20.1.5.4:
C>

C>— The typedef members pointer, const_pointer, size_type, and
C>difference_type are required to be T*,T const*, size_t, and ptrdiff_t,
C>respectively.

C>Точнее, этот пункт надо изменить, чтобы можно было использовать умные
C>указатели.
+1

>> C>Деструкторы в принципе не живут вместе с GC.
>> Знаю Можно было бы автоматически генерировать finalize, убрав delete
>> объектов, и вызов деструкторов базовых классов и членов.
C>Тоже не надо. Финализатор — это все же совсем другая сущность (вспомним
C>твой пример с C++/CLI), так что лучше его не смешивать с деструкторами.
Помню
Лучше бы динамический тип менялся, хотя бы в C++0x...
Буду ломиться в comp.lang.c++.std, чтобы после вызова finalize,
перед вызовом finalize базового класса, сменить тип.
Хотя вряд-ли получится — finalize обычная виртуальная функция.

Pavel Chikulaev wrote:
>> > C>Не впечатляет, честно говоря.
>> > Что именно не нравиться?
> C>Не вижу смысла в этом.
> Ну ты недавно лишь говорил, что GC иногда нужен...
Нужен. Но вот консервативный GC не особо хочется — лучше уж как в GCC
или Boost.xpressive написать свой GC для частного случая.

>> > Еще один повод разрешить переопределять operator .
> C>Давно пора бы.
> Эх. Ну почему его нет в C++98 (
Пиши proposal

> C>Нет уж. В моем дизайне mapped-класс может быть распределен обычным не-gc
> C>оператором new или создан на стеке, при этом семантика деструкторов
> C>остается та же. А вот финализация будет использоваться только совместно
> C>с GC.
> Тоже самое. Если создание с помощью new — не использовать ~T,
> с помощью new(gc) или лучше gcnew — тогда использовать ~T.
Я пытался придумать дизайн, требующий минимальных изменений и не очень
неинтуитивный.

> C>Тоже не надо. Финализатор — это все же совсем другая сущность (вспомним
> C>твой пример с C++/CLI), так что лучше его не смешивать с деструкторами.
> Помню
> Лучше бы динамический тип менялся, хотя бы в C++0x...
> Буду ломиться в comp.lang.c++.std, чтобы после вызова finalize,
> перед вызовом finalize базового класса, сменить тип.
Просто тут мы дублируем механизм деструкторов. А нам такое не нужно

--
С уважением,
Alex Besogonov (alexy@izh.com)