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

C>В С++ деструктор тоже не удаляет объект (этим занимается operator
C>delete), а освобождает связанные с объектом ресурсы. Именно этим же и
C>занимается Dispose.

Не совсем. Как раз этим занимается Finalize (гарантия вызова Finalize есть, гарантии вызова Dispose нет).

C>Может быть. Хотя может и стоит изменить семантику хранения.

Да, это прийдётся сделать, если в CLI захочется эффективно хранить N объектов "подряд" (грубо говоря).

C>Вот с множественным наследованием (и интерфейсам) все сложнее.

Может, поэтому множественное наследование и отсутствует в C#, что не захотели усложнять? Мне в смысле множественного наследования больше нравится идея с миксинами — мы явно указываем, что реализация интерфейса второго (третьего и т.д.) класса, который мы как бы "наследуем", будет вынесена в отдельный объект, агрегированный нашим классом.

Собственно, именно так сейчас "множественное наследование" и делается в C# — класс наследуется от интерфейса, реализация интерфейса в классе переадресует вызовы внутреннему объекту, содержащему стандартную реализацию интерфейса.

В общем, рассуждать на эту тему можно долго и плодотворно (или неплодотворно). Возвращаясь к теме топика, меня вполне устраивает то, как CLI работает сейчас в случае вызова фиртуальных методов из Finalize — при правильном дизайне проблем с этим не бывает.

Oyster wrote:
> C>В С++ деструктор тоже не удаляет объект (этим занимается operator
> C>delete), а освобождает связанные с объектом ресурсы. Именно этим же и
> C>занимается Dispose.
> Не совсем. Как раз этим занимается Finalize (гарантия вызова Finalize
> есть, гарантии вызова Dispose нет).
Finalize вообще надо в морг отправить. Абсолютно неюзабельная вещь в
серьезных программах. Единственное назначение Finalize — чтобы написаные
левой пяткой программы хоть как-то работали.

Семантический аналог деструктора — это именно Dispose.

> C>Может быть. Хотя может и стоит изменить семантику хранения.
> Да, это прийдётся сделать, если в CLI захочется эффективно хранить N
> объектов "подряд" (грубо говоря).
Да, было бы неплохо.

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

> Мне в смысле множественного наследования больше
> нравится идея с миксинами — мы *явно* указываем, что реализация
> интерфейса второго (третьего и т.д.) класса, который мы как бы
> "наследуем", будет вынесена в отдельный объект, агрегированный нашим
> классом.
Тогда начнутся сложности с иерархией миксинов.

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

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

C>Finalize вообще надо в морг отправить. Абсолютно неюзабельная вещь в
C>серьезных программах. Единственное назначение Finalize — чтобы написаные
C>левой пяткой программы хоть как-то работали.

Ты предлагаешь избавиться от него вообще? Просто я не вижу лучшей альтернативы в CLI, которая среда с GC (Dispose не предлагать — я могу его и не вызвать).

C>Семантический аналог деструктора — это именно Dispose.

Скажем так — в CLI сейчас нет аналога деструктора вообще Называть Dispose аналогом деструктора в его текущем виде у меня рука не поднимается.

C>Да, было бы неплохо.

Да ну — нафиг надо, на самом деле. Имхо и сейчас всё очень даже хорошо.

C>Но есть интерфейсы — с ними те же проблемы, на самом деле.

Нет, не те же, т.к. у интерфейсов нету состояния. В итоге вопрос с реализацией нескольких интерфейсов достаточно просто разруливается в CLR.

C>Тогда начнутся сложности с иерархией миксинов.

Вот тут я промолчу — сказывается недостаток знаний.

Oyster wrote:
> Ты предлагаешь избавиться от него вообще?
Да. Точнее, оставить в качестве отладочного средства — чтобы в Finalize
можно было поставить большой матюгальник, если ресурсы не будут закрыты
вовремя.

> Просто я не вижу лучшей альтернативы в CLI, которая среда с GC (Dispose
> не предлагать — я могу его и не вызвать).
Вот. Именно поэтмоу нужны автоматические объекты с семантикой как в С++.
И это даже не потребует никак изменений в самом CLI — достаточно чтобы
компилятор сам оборачивал их в try..finally.

> C>Семантический аналог деструктора — это именно Dispose.
> Скажем так — в CLI сейчас нет аналога деструктора *вообще* Называть
> Dispose аналогом деструктора в его текущем виде у меня рука не поднимается.
Именно поэтому и нужно их нормально вводить. Идеально было бы ввести
автоматические типы с семантикой как в С++ (в том числе и для
деструкторов), а остальное можно было бы и не трогать.

> C>Но есть интерфейсы — с ними те же проблемы, на самом деле.
> Нет, не те же, т.к. у интерфейсов нету состояния. В итоге вопрос с
> реализацией нескольких интерфейсов достаточно просто разруливается в CLR.
Я про то, что вызов метода по интерфейсу происходит дольше прямого вызова.

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

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

C>Да. Точнее, оставить в качестве отладочного средства — чтобы в Finalize
C>можно было поставить большой матюгальник, если ресурсы не будут закрыты
C>вовремя.

Спорное утверждение. А ежели никто не озаботился вызовом Dispose? А ежели у нас объект долгоживущий, и RAII не получается использовать?

Получаемся, меняем шило на мыло (одно соглашение на другое).

C>Вот. Именно поэтмоу нужны автоматические объекты с семантикой как в С++.
C>И это даже не потребует никак изменений в самом CLI — достаточно чтобы
C>компилятор сам оборачивал их в try..finally.

Хочется RAII? Кстати, разве такого в C++/CLI нету?

C>Именно поэтому и нужно их нормально вводить. Идеально было бы ввести
C>автоматические типы с семантикой как в С++ (в том числе и для
C>деструкторов), а остальное можно было бы и не трогать.

См. выше.

C>Я про то, что вызов метода по интерфейсу происходит дольше прямого вызова.

А. Ну да. Я серьёзной проблемой считал проблему поддержания состояний всех наследуемых классов в случае множественного наследования.

Oyster wrote:
> C>Да. Точнее, оставить в качестве отладочного средства — чтобы в Finalize
> C>можно было поставить большой матюгальник, если ресурсы не будут закрыты
> C>вовремя.
> Спорное утверждение. А ежели никто не озаботился вызовом Dispose?
Сразу получит в лоб ассертом (или чем нибудь еще) из финализатора после
первого же запуска.

Просто сейчас УЖЕ есть куча программ, в которых открываются критичные
ресурсы (типа файлов на запись), а потом не закрываются. В результате
ошибки вылавливаются в production'е, когда из-за какой-то смены погоды
на Марсе объект не прибивается GC в первый проход.

> А ежели у нас объект долгоживущий, и RAII не получается использовать?
RAII замечательно используется для долгоживущих объектов — просто надо
ввести понятие конструктора копирования и перемещения.

> C>Вот. Именно поэтмоу нужны автоматические объекты с семантикой как в С++.
> C>И это даже не потребует никак изменений в самом CLI — достаточно чтобы
> C>компилятор сам оборачивал их в try..finally.
> Хочется RAII? Кстати, разве такого в C++/CLI нету?
Есть. Но сам C++/CLI пока как-то не очень привлекает. Лучшая реализация
из всех, что я видел — это язык D.


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

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

C>Сразу получит в лоб ассертом (или чем нибудь еще) из финализатора после
C>первого же запуска.

C>Просто сейчас УЖЕ есть куча программ, в которых открываются критичные
C>ресурсы (типа файлов на запись), а потом не закрываются. В результате
C>ошибки вылавливаются в production'е, когда из-за какой-то смены погоды
C>на Марсе объект не прибивается GC в первый проход.

Т.е. если объект реализует IDisposable, для него автоматически генерируется некий код в Finalize? Или он для всех классов автоматически генерируется? Какое огромное поле для неочевидных багов

C>RAII замечательно используется для долгоживущих объектов — просто надо
C>ввести понятие конструктора копирования и перемещения.

Считать ссылки, что ли? Отличное решение — очень в духе C++

Всё-таки Finalize и Dispose Pattern мне нравятся больше. Или ты полагаешь, что с предложенным тобой решением совершенно не будет геморроя?

C>Есть. Но сам C++/CLI пока как-то не очень привлекает. Лучшая реализация
C>из всех, что я видел — это язык D.

Ты бы тогда и на C# не перешёл, если б там a-la-RAII появилось... и ради кого тогда делать такое изменение?

Oyster wrote:
> C>Просто сейчас УЖЕ есть куча программ, в которых открываются критичные
> C>ресурсы (типа файлов на запись), а потом не закрываются. В результате
> C>ошибки вылавливаются в production'е, когда из-за какой-то смены погоды
> C>на Марсе объект не прибивается GC в первый проход.
> Т.е. если объект реализует IDisposable, для него автоматически
> генерируется некий код в Finalize?
НЕТ. Вообще забудьте слово Finalize.

> Или он для всех классов автоматически генерируется? Какое огромное
> поле для неочевидных багов
Все просто — если в классе есть автоматические поля, то они должны быть
освобождены в момент финализации. В автосгенерированом финализаторе это
можно проверять и орать в лог о нарушениях.

> C>RAII замечательно используется для долгоживущих объектов — просто надо
> C>ввести понятие конструктора копирования и перемещения.
> Считать ссылки, что ли? Отличное решение — очень в духе C++
Не обязательно — нужно вспомнить про политики владения: монопольную,
эстафетную, разделяемую и т.п.

> Всё-таки Finalize и Dispose Pattern мне нравятся больше. Или ты
> полагаешь, что с предложенным тобой решением совершенно не будет геморроя?
Оно, по крайней мере, будет детерминированым. В отличие от
финализаторов, которые могут срабатывать в зависимости от погоды на Марсе.

> C>Есть. Но сам C++/CLI пока как-то не очень привлекает. Лучшая реализация
> C>из всех, что я видел — это язык D.
> Ты бы тогда и на C# не перешёл, если б там a-la-RAII появилось... и ради
> кого тогда делать такое изменение?
К сожалению, проекты на C#/Java я тоже пишу.

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

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

[... skipped ...]

Ну не нравится мне твоё решение Не вижу я, каким образом "автоматические объекты" помогут делу освобождения ресурсов. Уже сейчас можно делать детерминированную сборку ресурсов, юзая Dispose Pattern. Ты же хочешь, чтобы компилятор обязательно следил за тем, чтобы такая сборка происходила, в то время как будет достаточно просто нормального дизайна.

Кроме того, сейчас я не вижу, как именно предлагается реализовать эти самые "автообъекты". Детали какие-то есть в обсуждении, а общей картинки уловить не могу. Может, подробно опишешь? Типа как это будет работать + примеры кода.

А ещё меня пугает то, что вместо свободы действий ты предлагаешь наложить дополнительное ограничение. Боюсь, твоё предложение только сделает дизайн менее гибким, чем сейчас (впрочем, могу ошибаться, т.к. самого решения целиком не уловил).

Oyster wrote:
> Ну не нравится мне твоё решение Не вижу я, каким образом "автоматические
> объекты" помогут делу освобождения ресурсов. Уже сейчас можно делать
> детерминированную сборку ресурсов, юзая Dispose Pattern.
Dispose Pattern не помогает, если ресурс кладется в поле объекта.

> Ты же хочешь, чтобы компилятор обязательно следил за тем, чтобы такая сборка
> происходила, в то время как будет достаточно просто нормального дизайна.
К сожалению, код получается достаточно громоздкий.

> Кроме того, сейчас я не вижу, как именно предлагается реализовать эти
> самые "автообъекты". Детали какие-то есть в обсуждении, а общей картинки
> уловить не могу. Может, подробно опишешь? Типа как это будет работать +
> примеры кода.
Берем С++, пример обертки для файла:

class FileHandle
{
    HANDLE nativeHandle;
public:
    //Конструируем по имени
    FileHandle(string filename)
    {
        nativeHandle=OpenFile(filename);
    }
    //Копирующий конструктор (пока забудем про
    //оператор присваивания)
    FileHandle(const FileHandle &_other)
    {
        nativeHandle=DuplicateHandle(_other.nativeHandle);
    }
    //Деструктор
    ~FileHandle()
    {
        CloseHandle(nativeHandle);
    }

    void ReadFile(...);
    void WriteFile(...);
};

Использовать очень просто:

void someFunc()
{
    FileHandle blah("c:\\...");
    blah.Read(...);
//Деструктор выполнится автоматически при выходе из блока,
//в том числе и при броске исключений. По сути, это Dispose-паттерн.
}

FileHandle getLogFile()
{
    string logName=...;
    FileHandle res(logName);
    return res;
//В 'return res' происходит создание ЕЩЕ одного объекта FileHandle
//и вызова у него копирующего конструктора. При это создается _копия_
//объекта 'res'. Затем исходный объект 'res' уничтожается - вызывающий
//получает временный объект FileHandle.
}

//Структура с двумя файлами, деструктор генерируется автоматически,
//в нем происходит вызов деструкторов членов.
struct TwoFiles
{
    FileHanlde one, two;
};
TwoFiles someFunc5()
{
    TwoFiles res;
    res.one=getLogFile();
    res.two=FileHandle("c:\\...");
    return res;
}

//Используем
FileHandle some;
{
    TwoFile fl=someFunc5();
    some=fl.one;
}

Можно еще более сложные примеры приводить. Первый случай использования —
по сути тот же Dispose-паттерн, но вот остальные не имеют аналогов в C#.

Лучше всего это сейчас сделано в D:
http://www.digitalmars.com/d/memory.html (см. секцию про RAII)

> А ещё меня пугает то, что вместо свободы действий ты предлагаешь
> наложить дополнительное ограничение.
Да, именно дополнительное ограничение, чтобы можно было отлавливать
болье ошибок еще на этапе компиляции.

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

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

PC>В CLI нет ООП.

ЕэсссЪ! Это же разоблачение века!!!

Кстати, под CLI ты что понимашь? Может лучше применять или термин C++/CLI (от же МС++2) или CLR, а то CLI очень уж свободный термин.

PC> А именно:
PC>Пусть у нас есть Base и Derived : Base. В CLI отношения "is-a" в момент разрушения/удаления/собирания объектов, т.к. подобъект Base не является Base, Derived части уже нет, а объект все еще является Derived, и соответственно виртуальные функции могут обращаться к данным которых уже нет.

Знашь, я не знаю кто такой "подобъект Base", но я точно знаю, что в CLR нет понятия деструктора и детерминированной финализации. CLR просто позволяет вызвать метод объекта с сигнатурой

virtual void Finalize();

А то что в Шарпе синтаксис похож на конструктор и производится неявный вызов финализатора базового класса — это всего лишь реализация встроенная в Шарп. Видимо не хотели напугать С++-ников радикальным отличием идеологии. Вот только она все равно радикально другая. Так что попытка явно неудачная.

Финализатор всегда вызвается у неразрушенного объетка. Более того. В CLR вообще нет понятия разрушения объекта! Темболее в нем нет понятия последовательного разрушения. Объект или есть, или нет. Объект есть если на него есть хотя бы одна ссылка. И объекта нет если на него нет ссылок. Других приципов нет. И это нужно просто понять. Ну, другая идеология. С глаз долой — из сердца вон.

Кстати, совершенно бессмысленно вызвать Dispose-ы вложенных объектов из финалайзера. Все равно финалайзер вызывается истемой. Так что как тут правильно сказали рядом "курите паттерн диспоз". Ну, для тех кто вкурить неможет придумали исключение. При неправильной логике ты просто получишь исключение, проанализируешь колстэк и поймешь в чем был неправ. Это моло чем отличается от банального повторного вызова деструктора.

PC>Вопрос:
PC>Зачем так сделали? Я просто не понимаю...

Причины две. Первая — хотели уйти от той прорвы граблей которое С++ подарил миру. Вторая — за каким-то лешим все же хотели чтобы синтаксис финилизаторов походил на С++-ный. Мне кажется, правильно было бы не косить под С++-ные деструкторы и не "помогать народу". Нужно было сделать как в Васике — позволить реализовывать финалайзеры и переопределять их с помощью банального ovveride. Тогда и вопроса бы не возникло. Ведь просто вызывается виртуальный метод.

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

Попробуй подумать над вот такой штукой:

using System;

class A
{
    ~A() { GC.ReRegisterForFinalize(this); }
}

class B : A
{
    ~B()
    {
        Console.WriteLine("Я объект класса 'A'. "
            + "Кажется я помираю... :( Но я пока жив! :)");
    }
}

class Program
{
    static void Main()
    {
        new B();
    }
}

Забавно? Правда?

Так что вызовы из "деструкторов" виртуальных методов — это еще цветочки. Вот воскресающие объекты — это куда прикольнее. Как тебе необязательность деструкторов?

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

PC>gcroot на someclass есть, пока не вызван finalizer (или ошибаюсь?)

Он есть до тех пор пока объект жив. То есть все время пока вызвается финалайзер. И не факт, что не останется после него. Так что любые предположения о жизни объектов на основании того вызван финалайзер или нет не верны.

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

O>Ошибаешься. Поскольку на сам родительский класс ссылок нету, то и на someClass их уже неду (из объектов, на которые никто не ссылается, ссылки не считаются). Почитал бы про GC

Автор(ы): Игорь Ткачев
Дата: 06.12.2002
Алгоритм работы сборщика мусора (garbage collector, далее просто GC), являющегося частью CLR, подробно описан в книге Джефри Рихтера (Jeffrey Richter) «Applied Microsoft .NET Framework Programming». Мы не будем приводить здесь столь же подробное описание этого алгоритма, но обязательно остановимся на некоторых ключевых моментах.

.

Есть, есть. Наличие финалайзера заставляет положить ссылку на объект сначала в очередь финализации, а потом в freachable-очередь (как раз ее читает поток финализации чтобы вызвать финалайз для объектов). Вот как раз freachable и является корнем ЖЦ.

PC>>Почему не меняют адрес виртуальной функции? Эт не правильно Derived части ж нет....

O>Опять ошибаешься — она есть, т.к. объект собирается не по частям, а целиком.

Ага. Я бы даже ответил проще. Как же можно поменять адрес виртуальной функции у объекта? Ведь она же виртуальная! У объекта этого класса других в общем-то и нет.

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

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

PC>[snipped]
PC>Ок. Тогда попробуй объяснить почему не происходит смена динамического типа после вызова Derived::Finalize и/или Derived::IDisposable::Dispose ? Где логика. Некоторые Derived части могут быть измененены\удалены...

Прикольно. Давай ты сам попробушь ответить на этот вопрос. Только я тебе его перепишу на С++:

struct Base
{
    virtual void Finalize()
    {
        printf("Base::Finalize();\n");
    }
};

struct Derived : public Base
{
    virtual void Finalize()
    {
        printf("Derived::Finalize();\n");

        Base::Finalize();
    }
};

void main()
{
    Base* a = new Derived();
    a->Finalize();
}

Почему не не происходит смена динамического типа после вызова Derived::Finalize?
Только не надо говорить, что Finalize вызывается не из деструктора. ОК? Ведь в дотнете и C# вообще нет деструкторов.

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

O>А чем она хороша, особенно в managed environment? Иметь 10 объектов в куче вместо одного — просто замечательная идея Ещё и косвенные вызовы появляются — тоже супер. И я просто не знаю, как бы в таком случае работал reflection или сериализация...

Кстати, С++-компиляторы тоже никаких левых объектов не создают, а "изменение адресов" просто эмулируется. И вообще, уж где ООП точно пока нет, так это в x86-ассемблере.

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

O>>На данный момент в CLI объекты reference-типа хранятся в куче. Каждый объект хранится в куче отдельно. Предложенная модификация повлечёт за собой изменение способа конструирования/хранения/сбора объектов — оно надо?
PC>Чуть изменить GCHandle и все будет легко...

Ого! Ну, ты дал. Ты уверен что четко понимашь, что такое GCHandle?

O>>Точно — чего-то мне smart pointers в C# не хватает
PC>RAII, smart_ptr лишь способ

Для RAII как раз и придуманы IDisposable и using.

O>>Дело в том, что в C# сложные вещи можно делать проще и чего-то совершенно не тянет делать их очень сложно
PC>Ага std::set как?

И в чем с ним проблема?

O>>PS: ты забыл предложить перенести BOOST на C# А то как же тут без него?
PC>язык простой слишком

Ага. Ошибок почти нет. Приходится сильно напрягаться чтобы жизнь не стала скучной.

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

C>Finalize вообще надо в морг отправить. Абсолютно неюзабельная вещь в
C>серьезных программах.

Ой, а можно список несерьезных программ?
Вот наш сайт серьезная программа? Я вот сейчас глянул, а там по статистики постянно появляются выжившие в результате финализации объекты. Прикино, что было бы если они все привращались в потери неуправляемых ресурсов?

C> Единственное назначение Finalize — чтобы написаные
C>левой пяткой программы хоть как-то работали.

Это у кого как. У кого как ты говоришь, а у кого для облегчения слежения за ресурсами и чтобы пара мелких ошибок не приводила к остановке работы критически важных приложений.

C>Семантический аналог деструктора — это именно Dispose.

Диспоз — это паттерн. И в его полную версию входит использования финализатора. Так что симантических аналогов деструкторов в дотнете нет.

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

C>Просто сейчас УЖЕ есть куча программ, в которых открываются критичные
C>ресурсы (типа файлов на запись), а потом не закрываются. В результате
C>ошибки вылавливаются в production'е, когда из-за какой-то смены погоды
C>на Марсе объект не прибивается GC в первый проход.

Примеры подобных проблем в реальной жизни можно привести?

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

C>Dispose Pattern не помогает, если ресурс кладется в поле объекта.

Это с чего же? Может просто понять, что ресурс лежащий в поле уже является обернутым финалайзером? Знаешь, что это значит? Это значит, что даже если ты не сделашь финалайзер у внешнего объекта или сделашь, но забудеш в нем дернуть некий диспоз, то все равно в момент когда умрет этот внешиний объект умрет и вложенный объект. А это значит, что у вложенного объекта вызовится финалайзер.

Именно по этому в дотнете принято делать очень логкие обертки над разными хэндлами и т.п., а не создавать иерархии управляемых объектов. Иначе бы любой массив обязан был бы реализовывать разные диспозы и вызывать их у всех вложенных объектов. А вдруг у них есть диспоз?

>> Ты же хочешь, чтобы компилятор обязательно следил за тем, чтобы такая сборка
>> происходила, в то время как будет достаточно просто нормального дизайна.
C>К сожалению, код получается достаточно громоздкий.

Да? Можно примеры? А то вот у меня на работу с неуправляемыми ресурсами в программах тратится где-то 0.1% уселий и кода.

C>//Структура с двумя файлами, деструктор генерируется автоматически,
C>//в нем происходит вызов деструкторов членов.
C>struct TwoFiles
C>{
C> FileHanlde one, two;
C>};
C>TwoFiles someFunc5()
C>{
C> TwoFiles res;
C> res.one=getLogFile();
C> res.two=FileHandle("c:\\...");
C> return res;
C>}

О. Вот тут и начинается дизайн приложения. И то что ты привык к кривому дизайну удерживающему ресурсы очень долго еще не значит, что нельзя по другому.

В дотнете есть прицип. Держи ресурсы только если они тебе нужны и пока они тебе нужны. Тот же файл можно и повтоно открыть. Или считать все что нужно из файла и забыть про него.

C>Лучше всего это сейчас сделано в D:
C>http://www.digitalmars.com/d/memory.html (см. секцию про RAII)

D — это тупиковая ветвь эволюции. Будь в нем RAII или еще что в сто раз лучше чем где-бы то нибыло, но язык этот проиграл еще будучи в проекте. Ведь невооруженным взглядом видно, что развитие идет в сторону надежности и безопасности. Думаю, что С++ — это псоледний не типобезопасный язык завоявавший популрность. Единственно почему люди отказыаются от безопасности — это скорость. Так вот этот аргумент все эфемернее и эфемернее. Ведь уже сейчкас текущие реализации безопасных языков показывают очень нехилые результаты. А учитывая количество ислледований посвященных устранению оверхэда вызваемого безопасностью с уверенностью можно сказать, что в будущем эта проблема исчезент вовсе.