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

EP>>Во-вторых, совершенно без разницы. Я показываю, что EA тут не даёт никакой type safety. Эта type safety в управляемых языках есть и без EA, а в C++ возможна без EA.
S>Я понимаю, что вы показываете. Я вам пытаюсь объяснить, что подход управляемых языков — "давайте начнём с корректной программы (т.е. с type safety), а затем сделаем её быстрой (например, снизим нагрузку на GC путём EA)".

По факту же, когда нужно "сделать быстрой", нагрузку с GC снимают off-heap'ом или подобными костылями. То есть escape в прямом смысле, от слов "рвём когти"
Причём со всеми атрибутами вида "объект под указателем(индексом) уничтожен, и запись по указателю портит новый объект"

S>А в С++ подход "давайте начнём с быстрой программы (т.е. дадим пользователю самому управлять временем жизни объектов), а потом безуспешно будем пытаться сделать её корректной".

Почему безуспешно то? Это какой-то уж совсем жёсткий bias, настолько жёсткий — что даже совсем не интересно

Вообще, это уже пошли попытки натянуть совуEA на глобусtype safety, вместо того чтобы просто признать, что изначальный тезис на поверку оказался неверен:

S>О, ещё немного — и вы изобретёте escape analysis.

EP>>Ты говоришь про общий случай. Для общего случая в C++ возможен только conservative GC, что уже обсуждалось выше по топику.
S>Ну, вот и договорились.

С этим никто и не спорил.

S>>>Разговор о том, что у вас нет никакой гарантии, что "GC использован только для части приложения", из-за потенциальной возможности прикопать указатель где угодно.
EP>>Теоретически.
EP>>А практически, для таких сценариев и при необходимости гарантий (например при невозможности достижения их одними guidelines) — можно запретить брать raw указатели на такие GC объекты — частично языком + простейшим внешним верификатором.
S>У нас с вами противоположные понятия о "теоретически vs практически". Я считаю, что ваша идея про необходимость гарантий — это чистая теория, не подтверждённая на практике. А практика — это наличие а) компиляторов, которые неспособны запрещать брать указатели на особые объекты, в том числе и непреднамеренно,

К Clang'у легко делаются plugin'ом, которые pattern match'ат куски AST. Реализовать PM по использованию конструкций std::addressof и т.п. на gc_ptr<T> — там относительно просто.
А отсутствие готового или малая известность — скорей всего от низкой востребованности

S>б) библиотек, которые несовместимы с такими ограниченными объектами, и с) наработанной прикладной кодовой базы на основе компиляторов и библиотек, которую никто не возьмётся переписывать в светлое будущее ради того, чтобы получить хоть какие-то гарантии в одном крошечном кусочке нашего проекта с 15-летней историей.

То есть проект 15 лет работал себе, без необходимости гарантий, а тут вдруг понадобились?
В любом случае, precise GC — это не единственный способ получить их. Например достаточно упомянутых выше region'ов

EP>>>>По-хорошему, нужно и минимизировать баги, и их последствия. В разных приложениях естественно нужен разный баланс.
S>>>Совершенно верно. Юмор в том, что С++ не позволяет ни того, ни другого.
EP>>А кто тогда позволяет? ObjectDisposed и OutOfBounds?
S>Конечно.

И как они помогают минимизировать баги?

WH>В случае C# пользователь иногда будет получать сообщение: "Извыни дарагой. Нешмагла. У програмыст рука кривой. В него ужа патинка полетел."

И кстати, на счёт ObjectDisposed — с помощью ref-counted подобная ситуация

Автор: Evgeny.Panasyuk
Дата: 08.10.14

разгуливается элементарно. Как бы сделать это на C#?

EP>>Так это реальный C++, удовлетворяющий стандарту, а не аналог
S>Покажите мне этот "реальный C++". Увы — он существует только в вашем воображении.

Смотри valgrind и sanitizer'ы.

EP>>shared state — это ref counted объект, грубо говоря std::shared_ptr<bool>. На него ссылаются и сам объект и все указатели.
EP>>При разрушения объекта, он всего лишь записывает в этот флаг false.
S>Да, так будет работать. Интересно, отчего эта техника не применяется в управляемых средах?

От того что там применяется другая техника, с другими характеристиками: "продление жизни объекта до тех пор пока на него есть последняя ссылка", а не "даём возможность узнать при доступе по ссылке — мёртв он или нет".

Точнее для IDisposable — там как раз что-то подобное и применяется. Только считай что shared sate встроен в объект, со всеми вытекающими. Например объект уже Disposed, а память занимаемая им всё ещё держится, так как есть ссылки
Для C++, кстати, тоже можно так сделать, необязательно отдельный shared state — но так будет излишний перерасход памяти