Хочу узнать мнение народа о будущем С++/CLI. Просмотрел интервью Герба Саттера (гл. архитектор С++) с Channel 9 на MSDN. Я так понял, что С++ будет мощным языком для платформы .NET, безопасным и дающим больше возможностей при работе например с generics. Интересно, а он будет поддерживать стандарт С++ 98го года, т.е. просто добавят новые возможности для работы с .NET ?
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Kisloid пишет:
> Хочу узнать мнение народа о будущем С++/CLI. Просмотрел интервью Герба > Саттера (гл. архитектор С++) с Channel 9 на MSDN. Я так понял, что С++ > будет мощным языком для платформы .NET, безопасным и дающим больше > возможностей при работе например с generics. Интересно, а он будет > поддерживать стандарт С++ 98го года, т.е. просто добавят новые > возможности для работы с .NET ?
Это будет уже не С++, а нечто. Убрали самые важные компоненты языка:
автоматические объекты и детерминированные деструкторы.
C>Это будет уже не С++, а нечто. Убрали самые важные компоненты языка: C>автоматические объекты и детерминированные деструкторы.
А по-русски можно, пожалуйста? А то я в терминах не силен.
Здравствуйте, Cyberax, Вы писали:
C>Это будет уже не С++, а нечто. Убрали самые важные компоненты языка: C>автоматические объекты и детерминированные деструкторы.
Здравствуйте, ansi, Вы писали:
C>>Это будет уже не С++, а нечто. Убрали самые важные компоненты языка: C>>автоматические объекты и детерминированные деструкторы. A>А по-русски можно, пожалуйста? А то я в терминах не силен.
. Там как раз таки весь смысл в автоматических (стековых) переменных — создаете вы их сами, а уничтожаются они деструктором — причем как раз таки {b]детерминированно[/b] — грубо говоря, всегдя можно сказать когда и в какой последовательности будут уничтожены стековые объекты. В CLI же деструкторов нету (есть этот невменяемый Dispose, кажись) и все оюъекты (которые, к тому же, в общем случае, создаются в куче) убиваются GC — но уже нельзя сказать ни о последовательности их умерщвления, ни о том, когда они будут уничтожены.
Это и представляет большую проблему — к примеру, нельзя просто написать менеджед-wrapper анменеджед ресурсов — к примеру, класс File. Ведь по логике деструктор должон осмободить дескриптор (ну и файл закрыть) — ан нет. То есть закрыть то он закроет, но непонятно когда. Посему заметьте интерфейс IDisposable и конструкцию using.
Это просто пример для файла. А ведь есть еще соединения с БД, всякие объекты ядра/GDI...
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, igna, Вы писали:
I>Здравствуйте, Cyberax, Вы писали:
C>>Это будет уже не С++, а нечто. Убрали самые важные компоненты языка: C>>автоматические объекты и детерминированные деструкторы.
I>Разве?
I>http://msdn.microsoft.com/visualc/homepageheadlines/ecma/
Здравствуйте, nikogo, Вы писали:
N>А конкретнее можно?
18.11 Destructors and finalizers
Any native class or ref class can have a user-defined destructor. Such destructors are run at the times
specified by the C++ Standard:
• An Object of any type allocated on the stack is destroyed when that Object goes out of scope.
• An Object of any type allocated in static storage is destroyed during program termination. 10
• An Object that is allocated on the native heap using new, is destroyed when a delete is performed
on a pointer to that Object.
• An Object that is allocated on the CLI heap using gcnew, is destroyed when a delete is performed
on a handle to that Object.
• An Object that is a member of another Object is destroyed as part of the destruction of the enclosing 15
Object.
For the purposes of destruction, the native and CLI heaps are treated the same. The only difference between
the two heaps is the automation and timing of memory reclamation. In the case of the native heap, memory
is reclaimed manually at the same time as the delete, while in the case of the CLI heap, memory is
reclaimed automatically during garbage collection whether or not there was a delete. In addition, Objects 20
on the CLI heap are finalized, if a finalizer exists.
Any ref class can have a user-defined finalizer. The finalizer is run zero or more times by the garbage
collector, as specified by the CLI.
Здравствуйте, Kisloid, Вы писали:
K>Хочу узнать мнение народа о будущем С++/CLI. Просмотрел интервью Герба Саттера (гл. архитектор С++) с Channel 9 на MSDN. Я так понял, что С++ будет мощным языком для платформы .NET, безопасным и дающим больше возможностей при работе например с generics. Интересно, а он будет поддерживать стандарт С++ 98го года, т.е. просто добавят новые возможности для работы с .NET ?
Огромное будуйщее. Бизнес-приложения на нем не советую. С# значительно стройней, сохраняет нас от возможностей ошибиться убирая многие детали.
С++/CLI — более системное управление объектами в памяти, простота работы с unmanagement. Но обладает некоторым недостатком, его возможности намного превосходят стандарты CLS (соответсвенно, легко наткнутся на непереносимость модулей из другого языка, хотя и есть ). И он более сложен (введены различные типы ссылок и указателей).
По этому поводу был огромный флейм в котором я подредактировал свое мнение по поводу C++/CLI. Можно читать начиная с: здесь
Здравствуйте, GlebZ, Вы писали:
GZ>Огромное будуйщее. Бизнес-приложения на нем не советую. С# значительно стройней, сохраняет нас от возможностей ошибиться убирая многие детали. GZ>С++/CLI — более системное управление объектами в памяти, простота работы с unmanagement. Но обладает некоторым недостатком, его возможности намного превосходят стандарты CLS (соответсвенно, легко наткнутся на непереносимость модулей из другого языка, хотя и есть ). И он более сложен (введены различные типы ссылок и указателей).
, а просто перекрасили в соответствии с моделью CLI.
> A>А по-русски можно, пожалуйста? А то я в терминах не силен.
> В CLI же деструкторов нету (есть этот невменяемый Dispose, кажись) и все оюъекты (которые, к тому же, в общем случае, создаются в куче) убиваются GC — но уже нельзя сказать ни о последовательности их умерщвления, ни о том, когда они будут уничтожены.
Согласен. Однако это не означает, что какой-нибудь язык не может сделать так, чтобы невменяемый Dispose стал вполне вменяемым, связав его с деструкторами. Именно так и сделали в C++/CLI: там деструкторы ref классов связаны именно с Dispose, а не с Finalize, как это почему-то сделали в C#. И деструкторы, как и везде в C++, автоматически вызываются для локальных, глобальных переменных, членов классов и т.п. Поэтому, сохраняя принятые в C++ идиомы управления ресурсами (RAII), можно быть вполне уверенным в последовательности освобождения ресурсов в т.ч. и при программировании под CLI.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Kisloid, Вы писали:
K>Хочу узнать мнение народа о будущем С++/CLI. Просмотрел интервью Герба Саттера (гл. архитектор С++) с Channel 9 на MSDN. Я так понял, что С++ будет мощным языком для платформы .NET, безопасным и дающим больше возможностей при работе например с generics. Интересно, а он будет поддерживать стандарт С++ 98го года, т.е. просто добавят новые возможности для работы с .NET ?
Насколько мне известно к первому релизу полной поддержки дженериков не будет, так как констрэйны к ним пока еще не прикрутили.
И вообще складывается полное впечатление, что поддержика нового стиля явно пока недоработана.
Ну, а как язык. На МС++ тоже можно было писать дотнетные програмы. Но народ обычно предпочитал Шарп или Жлабэйсик.
Думаю новая версия МС++ будет востребована впервую очередь теми кто слишком сильно прикипели к С++ и не жалают расставаться с любимым языком. Таких не мало. Так что можно точно сказать, что он будет более востребован нежелни первая версия МС++.
Ну, а в тотальную гегемонию МС++ что-то не верится. Никаких реальных преимуществ перед Шарпом или ВБ в области создания чисто менеджед приложений у него не будет. А граматического мусора в коде будет призрядно. В купе с тем, что МС++ хуже интегрируется в разные средства автоматизации вроде IDE и MSBuild — это оттолкнет от него тех кто не был связан долгие годы с С++. Да и многие С++-ники в итоге перейдут на Шарп.
Ну, а где МС++ будет бесспорным лидером — это совершенно понятно. В области переноса С++-приложений под дотнет. Тут у него конкурентов нет. Ведь можно будет практически без переписывания откомпилировать обычное Виндвс-приложение на МС++ и получить возможность расширять приложения всеми средствами доступными в дотнете.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Это будет уже не С++, а нечто. Убрали самые важные компоненты языка: C>автоматические объекты и детерминированные деструкторы.
Не нужно придумывать. Ничего никуда не убрали. В язык встроили дополнительные средства для общения с управляемым миром.
Деструкторы же наоборот приделали даже к менеджед-обхектам.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, ansi, Вы писали:
C>>>Это будет уже не С++, а нечто. Убрали самые важные компоненты языка: C>>>автоматические объекты и детерминированные деструкторы. A>>А по-русски можно, пожалуйста? А то я в терминах не силен.
Н>Посмотри Gdi Objects Selector
. Там как раз таки весь смысл в автоматических (стековых) переменных — создаете вы их сами, а уничтожаются они деструктором — причем как раз таки {b]детерминированно[/b] — грубо говоря, всегдя можно сказать когда и в какой последовательности будут уничтожены стековые объекты.
Да уж. Супер технология. И как живут GDI+ с Авалоном?...
Н>В CLI же деструкторов нету (есть этот невменяемый Dispose, кажись) и все оюъекты (которые, к тому же, в общем случае, создаются в куче) убиваются GC — но уже нельзя сказать ни о последовательности их умерщвления, ни о том, когда они будут уничтожены.
Трепач находка для шпионов. (с) Ну, или иногда лучше молчать чем говорить. (с)
Отличительной особенностью новой вресии МС++ (С++/CLI) о которой идет речь в этой ветке как раз является возможность эмуляции деструкторов у управляемых объектов реализующих IDispose. Возможность использовать деструкторы у С++-объектов была с самого начала. Так что прежде чем начинать строить обвинительные заключения нужно хотя бы немгожко разобраться в теме. В этом форуме, кстати, не раз поднимался этот вопрос.
Н>Это и представляет большую проблему — к примеру, нельзя просто написать менеджед-wrapper анменеджед ресурсов — к примеру, класс File.
Мля, не только можно, но и ненужно. Вернее бессмысленно, так как любой объект реализующий IDispose можно просто использовать как стэковую переменную. Правда класса "File" в природе не существуют, но классы вроде FileStream или StreamReader можно спокойно объявлять таким образом:
И по выходу из области видимости у streamReader будет автоматически вызван Dispose().
Н> Ведь по логике деструктор должон осмободить дескриптор (ну и файл закрыть) — ан не Н>т. То есть закрыть то он закроет, но непонятно когда. Посему заметьте интерфейс IDisposable и конструкцию using. Н>Это просто пример для файла. А ведь есть еще соединения с БД, всякие объекты ядра/GDI...
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Честно говоря, из этой спеки я не особо понял сементику вызова C>деструкторов и их отношение к финализаторам. Буду рад, если я ошибаюсь.
VladD2,
> Насколько мне известно к первому релизу полной поддержки дженериков не будет,
Что такое полная поддержка generics — вопрос спорный. Полагаю, что подразумевается поддержка всех возможностей, доступных из C#. В этом смысле можно сказать, что возможностей и больше, и меньше одновременно: часть возможностей отсутствует, но есть некоторые дополнительные.
> так как констрэйны к ним пока еще не прикрутили.
Interface constraints есть, нет constraints value class и new. Насколько необходимо первое — вопрос открытый; очень желательно — 100%, но при дополнительных возможностях C++/CLI, по идее без них прожить можно. Второе легко обеспечивается прямым использованием Activator. Так что, имхо, ничего страшного.
> Ну, а где МС++ будет бесспорным лидером — это совершенно понятно. В области переноса С++-приложений под дотнет.
Не только. Т.к. в управлении ресурсами C++/CLI (на сегодня) дает больше возможностей, чем любые другие языки под .Net, и т.к. в нем заметно больше выразительных возможностей в определенных моментах (шаблоны, управляемые ссылки и т.п.), то можно предположить, что также C++/CLI будет более удобным еще в ряде случаев, вне зависимости от взаимодействия с неуправляемым кодом.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Kisloid, Вы писали:
K>Здравствуйте, GlebZ, Вы писали:
GZ>>Огромное будуйщее. Бизнес-приложения на нем не советую. С# значительно стройней, сохраняет нас от возможностей ошибиться убирая многие детали. GZ>>С++/CLI — более системное управление объектами в памяти, простота работы с unmanagement. Но обладает некоторым недостатком, его возможности намного превосходят стандарты CLS (соответсвенно, легко наткнутся на непереносимость модулей из другого языка, хотя и есть ). И он более сложен (введены различные типы ссылок и указателей).
K>Слушай, а что это такое : здесь
или твое мнение изменилось, и если да то почему ?
Да. Просто я узнал C++/CLI поближе. Пришлось изменить свое мнение. Синтаксис значительно улучшен по сравнению MC++. Даже лучше сказать, полностью переделан.
Что касается переноса приложений с С++, то я все равно голосую за С#. Переводить под С++/CLI — все равно нужно достаточно много потрудиться (хотя и меньше чем в MC++). Система ссылок и указателей для менеджед не такая как в обычных C++. Язык с его множеством указателей и ссылок достаточно сложен. Перевод на C# не слишком более сложен, но после этого можно получить читабельную, и стройно выстроенную программу. Но что касается взаимодействия с unmanaged кодом и адресацией по всем объектам(особенно value) — показывает что для системных вещей взаимодействия с unmanaged и небольших программ в которых производительность должна быть выше обычного — конкурентов нет (разве что писать сразу на CLI ).
Еще, с первого раза, мне не удалось выявить сразу стройную систему, когда код является верифицируемым, и когда он не является верифицируемым. Можно это списать на раннюю бету, которая стоит у меня. Надеюсь в дальнейшем это будет четко описано в документации. Но это также говорит о сложности языка для бизнес-приложений. Бизнес-приложения должны строится на безопасном, простом для refactoring, языке.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2,
>> Насколько мне известно к первому релизу полной поддержки дженериков не будет,
ПК>Что такое полная поддержка generics — вопрос спорный.
Не, вопрос элементарный. Полная — это так что есть в Шарпе. Причем просто потому, что она для него и делалась. Это уже потом решили всунуть их всюду. Отсюда и неполная поддержка плюсами.
ПК>Interface constraints есть, нет constraints value class и new. Насколько необходимо первое — вопрос открытый; очень желательно — 100%, но при дополнительных возможностях C++/CLI, по идее без них прожить можно. Второе легко обеспечивается прямым использованием Activator. Так что, имхо, ничего страшного.
Причем тут активатор? Ты не можешь описать всех возможностей предоставляемых дженериками. А значит не сможешь описать некоторые из дженериков. Так что Activator прийдется пользоваться уже в других языках.
>> Ну, а где МС++ будет бесспорным лидером — это совершенно понятно. В области переноса С++-приложений под дотнет.
ПК>Не только. Т.к. в управлении ресурсами C++/CLI (на сегодня) дает больше возможностей, чем любые другие языки под .Net,
Продолжай верить в свои сказки дальше. Я уже устал говорить, что проблемы с управлением ресурсами возникают только в интеропе.
ПК> и т.к. в нем заметно больше выразительных возможностей
И чё все строем не ходят?
ПК> в определенных моментах (шаблоны, управляемые ссылки и т.п.), то можно предположить, что также C++/CLI будет более удобным еще в ряде случаев, вне зависимости от взаимодействия с неуправляемым кодом.
Ну, естественно. Если нужно будет числа подробить на максимальной скорости, то всегда можно будет на МС++ кусок кода пометить анменеджед. Но об этом я вроде говорил. Ты просто пропустил.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> Что такое полная поддержка generics — вопрос спорный.
> Не, вопрос элементарный. Полная — это так что есть в Шарпе. Причем просто потому, что она для него и делалась.
Может, и так, но тот же C# поддерживает не все возможности generics.
> ПК> в управлении ресурсами C++/CLI (на сегодня) дает больше возможностей, чем любые другие языки под .Net,
> Продолжай верить в свои сказки дальше. Я уже устал говорить, что проблемы с управлением ресурсами возникают только в интеропе.
Не смешно. Даже если представить, что все целиком насквозь managed, как ты будешь закрывать сокет, соединение с базой данных или файл, о котором run-time понятия не имеет?
> Если нужно будет числа подробить на максимальной скорости, то всегда можно будет на МС++ кусок кода пометить анменеджед.
Речь далеко не только и не столько о дроблении чисел на максимальной скорости.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
А то я в терминах не силен.
И чё все строем не ходят?