Здравствуйте, bt, Вы писали:
bt>Здравствуйте, alexkro, Вы писали:
bt>... A>>Вообще, если хочешь проникнуться идеалогией C++/CLI читай блоги Саттера, Липмана и Брейя. bt>...
bt>Если не трудно, дайте ссылки где можно прочитать вышеупомянутое.
C++ managed classes can now have destructors, meaning C++ now has deterministic finalisation. The destructor implicitly implements the Dispose pattern of managed code and includes chaining, and is called when a stack-based object goes out of scope, a class member's enclosing object is destroyed or when delete is called. Having destructors means that the classic stack based pattern can be used, which means less try/catch/finally blocks and cleaner code.
Они настоящие!
Re: Whidbey for Visual C++ .NET - destructor chaining
Здравствуйте, desperado_gmbh, Вы писали:
_>Они настоящие!
Нет.
C++ managed classes can now have destructors, meaning C++ now has deterministic finalisation. The destructor implicitly implements the Dispose pattern of managed code and includes chaining, and is called when a stack-based object goes out of scope, a class member's enclosing object is destroyed or when delete is called. Having destructors means that the classic stack based pattern can be used, which means less try/catch/finally blocks and cleaner code.
Для менеджед-объектов "помещаемых" в стэк делается прокси. Сам объект хранится точкно так же в менеджед-хипе.
В общем, это идеология враперов незаметных невооруженным взглядом. Таким образом С++-программист будет видеть меньше подробностей работы системы чем Шарповик.
Так сказать вмонтированных в компилятор АТЛ для дотнета.
Кстати, с помощью таких же враперов можно будет "помещать" анменеджед-данные в менеджед-хип.
Так же обещают неявный боксинг и т.п. Но этого всего в PDC-шной версии Видби нет.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Whidbey for Visual C++ .NET - destructor chaining
Здравствуйте, VladD2, Вы писали:
VD>The destructor implicitly implements the Dispose pattern of managed code and includes chaining, and is called when a stack-based object goes out of scope, a class member's enclosing object is destroyed or when delete is called.
VD>Для менеджед-объектов "помещаемых" в стэк делается прокси. Сам объект хранится точкно так же в менеджед-хипе.
Да и пусть. Тем более что этот прокси и не обязан существовать в il, компилятору достаточно помнить про него и сгенерировать в конце функции finally-блок с Dispose. Для меня основная проблема с отсутствием деструкторов в c# не в необходимости вызывать Dispose на самом верху, а в необходимости реализовывать Dispose pattern в каждом классе, косвенно владеющем unmanaged-ресурсами.
VD>В общем, это идеология враперов незаметных невооруженным взглядом. Таким образом С++-программист будет видеть меньше подробностей работы системы чем Шарповик.
В c# lock, using и T::~T уже прячут подробности. Кажется, всех это только радует
Re[3]: Whidbey for Visual C++ .NET - destructor chaining
Здравствуйте, desperado_gmbh, Вы писали:
_>Да и пусть. Тем более что этот прокси и не обязан существовать в il, компилятору достаточно помнить про него и сгенерировать в конце функции finally-блок с Dispose. Для меня основная проблема с отсутствием деструкторов в c# не в необходимости вызывать Dispose на самом верху, а в необходимости реализовывать Dispose pattern в каждом классе, косвенно владеющем unmanaged-ресурсами.
Разработчики заявляют именно о прокси. Я согласен, что компилятор мог бы все сделать и на более низком уровне. Но за что купил...
_>В c# lock, using и T::~T уже прячут подробности. Кажется, всех это только радует
Для Шарпа это нормально. Он изначально язык более высокого уровня. T::~T там правда никакого нет. Там есть финалайзеры. Это не одно и тоже.
Проблема в том, что CLI/С++ не прячет все подробности. Он делает это изберательно. Нарваться на дэнглинг-поинтер и т.п. так же просто как и рашьше, но при этом кишки работы компилятора не видны. И это не только с финализацией (с ней-то получилось более менее красиво). Более логично было бы делать в С++ некие код-парерны. Это бы было ближе к идеологии языка. Пока что МС++ в дотнете используется как язык общения с анмедеджед-миром. И в этом качестве многие навороты из CLI/С++ оказаться вредны. CLI/С++ делается как я понимаю, чтобы облегчить создание дотнет-приложений без использования других языков. В общем-то цель хорошая. Но осуществлять ее в ущерб прозрачности тоже не выход. Будем надяеться, что можно будет выбирать синтаксис (с помошью и без).
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Whidbey for Visual C++ .NET - destructor chaining
Здравствуйте, VladD2, Вы писали:
_>>Да и пусть. Тем более что этот прокси и не обязан существовать в il, компилятору достаточно помнить про него и сгенерировать в конце функции finally-блок с Dispose. Для меня основная проблема с отсутствием деструкторов в c# не в необходимости вызывать Dispose на самом верху, а в необходимости реализовывать Dispose pattern в каждом классе, косвенно владеющем unmanaged-ресурсами. VD>Разработчики заявляют именно о прокси. Я согласен, что компилятор мог бы все сделать и на более низком уровне. Но за что купил...
В любом случае лучше подождать релиза и проверить.
_>>В c# lock, using и T::~T уже прячут подробности. Кажется, всех это только радует VD>Для Шарпа это нормально. Он изначально язык более высокого уровня.
Для плюсов тоже совершенно нормально генерировать нетривиальный код, например, для корректного вызова деструкторов локальных переменных при исключении.
VD>T::~T там правда никакого нет. Там есть финалайзеры. Это не одно и тоже.
Есть синтаксис ~T(){...}, превращающийся в финалайзер автоматическим дописыванием вызова предка в finally.
VD>Проблема в том, что CLI/С++ не прячет все подробности. Он делает это изберательно. Нарваться на дэнглинг-поинтер и т.п. так же просто как и рашьше, но при этом кишки работы компилятора не видны. И это не только с финализацией (с ней-то получилось более менее красиво). Более логично было бы делать в С++ некие код-парерны.
Да, там логичнее выставить из ядра минимальную функциональность, а остальное сделать классами и шаблонами.
Re[4]: Whidbey for Visual C++ .NET - destructor chaining
Здравствуйте, VladD2, Вы писали:
VD>Проблема в том, что CLI/С++ не прячет все подробности. Он делает это изберательно. Нарваться на дэнглинг-поинтер и т.п. так же просто как и рашьше, но при этом кишки работы компилятора не видны. И это не только с финализацией (с ней-то получилось более менее красиво). Более логично было бы делать в С++ некие код-парерны.
В том-то и дело, что вещи которые принимаются как должное в C++, в C++ with managed extensions стали требовать код-патернов. Эту проблему и должен решить C++/CLI.
> Это бы было ближе к идеологии языка. Пока что МС++ в дотнете используется как язык общения с анмедеджед-миром.
Пока что. С приходом C++/CLI ситуация должна измениться.
>И в этом качестве многие навороты из CLI/С++ оказаться вредны. CLI/С++ делается как я понимаю, чтобы облегчить создание дотнет-приложений без использования других языков. В общем-то цель хорошая. Но осуществлять ее в ущерб прозрачности тоже не выход.
Тут ты должен определить прозрачность. Если это способность угадать IL код, то да, ущерб. А если это легкость применения устоявшихся C++ идиом, то нет ущерба, только улучшения.
Вообще, если хочешь проникнуться идеалогией C++/CLI читай блоги Саттера, Липмана и Брейя.
> Будем надяеться, что можно будет выбирать синтаксис (с помошью и без).
Типа старый/новый? Можно будет использовать только один из них. Старый синтаксис остается для поддержки уже написанных программ. Новых возможностей (generics) там не будет.
Re[5]: Whidbey for Visual C++ .NET - destructor chaining
Здравствуйте, alexkro, Вы писали:
A>Типа старый/новый? Можно будет использовать только один из них. Старый синтаксис остается для поддержки уже написанных программ. Новых возможностей (generics) там не будет.
Читал, спасибо. Что же касается идей, то не проникся. Писать один фиг проще, быстрее и надежнее на Шарпе. А МС++ лично мне нужен как непривзойденный интероп. Однако я перкрасно понимаю зачем все это делается. Их задача пересадить на дотнет тех кто не принимает Шарп ни под каким соусом. Против этого лично я ничего не имею. Вот только в то, что создание менеджед-приложений на МС++ станет массовым мне не верится.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Whidbey for Visual C++ .NET - destructor chaining
