Здравствуйте, Plutonia Experiment, Вы писали:
PE>Поскольку язык сделан максимально безопастным, делегаты сделаны в нем нативными средсвами.
Никакой связи нет. Сигналы, например, построены на типобезопасных указателях на члены. Небезопасными в c++ являются static_cast на потомка и reinterpret_cast, которые не используются в реализации сигналов. Есть, правда, одно исключение (внутри any_cast используется static_cast вместо dynamic_cast), но оно сделано в целях эффективности и перед ним явно проверяется, что тип правильный.
Здравствуйте, desperado_gmbh, Вы писали:
_>Никакой связи нет. Сигналы, например, построены на типобезопасных указателях на члены. Небезопасными в c++ являются static_cast на потомка и reinterpret_cast, которые не используются в реализации сигналов. Есть, правда, одно исключение (внутри any_cast используется static_cast вместо dynamic_cast), но оно сделано в целях эффективности и перед ним явно проверяется, что тип правильный.
Любой указатель можно обойти тем или иным способом.
Никто не спорит, что буст для С++ — рульная вещь. Предложи дизайн для шарпа.
Буст — это С++ вариант. Как ты сможешь использоваться это для компонентов ?
Здравствуйте, VladD2, Вы писали:
VD>А. Ну-ну. Интересно как я погу знать о таких вещах даже не пробовав?
А что ты хотел? boost _бесплатная, эксперементальная_ библиотека.
Там просто мелкий недочет который можно исправить за пару часов.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
VD>>Да я вроде и без него в С++ разбирался. WH>Я тоже так думал...
WH>Из предисловия Скотта Мейерса WH>
WH>Если, прочитав материал, посвященный спискам типов, вы не свалились со стула, значит, вы сидели на полу.
Я не свалился , я был в восторге . Там, кстати, явно проглядывается лямбда-исчисление и функциональное программирование, по-моему. typedef — введение переменной, Func<A,B,C>::Result — вызов функции. Извращенно немножко, но похоже.
Здравствуйте, VladD2, Вы писали:
VD>Да конечно появление шаблонов откроет пути к совершенству.
Спорный вопрос. C# generics ничего общего с шаблонами не имеют. Пока что я для них одно применение вижу — типизированные контейнеры. Никакой новой парадигмы программирования они не откроют. Даже такая простая вещь как policy-based programming не станет возможна в C#.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, mihailik, Вы писали:
M>>А нет ли какой-нибудь толковой статьи на эту тему? Почему шаблоны так уж "откроют путь к совершенству"? Вроде вполне ограниченная технология на непредвзятый взгляд. WH>Скорее не опытный ИМХО. Александреску читал? boost потрошил?
А что, Александреску C# with generics в своей книге использует? Generics & templates — это разные вещи. Не нужно их возможности приравнивать.
Здравствуйте, alexkro, Вы писали:
A>Спорный вопрос. C# generics ничего общего с шаблонами не имеют.
Ну насчет ничего общего это ты загнул, но действительно — дженерики и плюсовые шаблоны это не одно и то же.
A>Пока что я для них одно применение вижу — типизированные контейнеры. Никакой новой парадигмы программирования они не откроют. Даже такая простая вещь как policy-based programming не станет возможна в C#.
Дженерики сделаны специально под дотнет. В них нет определенного функционала темплейтов, зато есть кое что, чего в темплейтах нет. Напиример темплейты в рантайме не видны, а дженерики видны. В общем каждому свое. Что такое policy-based programming я не знаю, если объяснишь что ты под этим подразумеваешь то народ подскажет как подобное реализуется в дотнете.
И еще, писать на дотнете, так как ты это делал на С++ не стоит, ничего хорошего из этого не выдет. Другая идеология, другие паттерны.
Здравствуйте, desperado_gmbh, Вы писали:
_>Делегат в .net не является прямым решением, это затычка, встроенная в компилятор:
Ты не путай делегат и событие, это не одно и то же. event в шарпе это действительно фича компилятора, а вот делегат поддерживается рантаймом. Достаточно поглядеть в исходники ротора.
_>В отличие от делегатов, boost/signal — прямое и законченное решение на шаблонах (тут рассказали про глюки с dll, но это поправимо и естественно для такой молодой и некоммерческой библиотеки, как boost), не требующее специальной поддержки компилятора.
Шаблоны ущербны в принципе — это не компонентное решение и никогда им не будет. Шаблоны вон в МС++ есть, только от этого толку никакого. Для дотнета нужно решение, которое способно работать в многокомпонентной и распределенной среде. Все на шаблонах красиво и хорошо, пока мы работаем в пределах одного процесса. Как только нам нужно вылезти за пределы процесса то все становится намного печальнее и вся красота пропадает. А если еще нам нужно чтобы было взаимодействие разных машин то все становится совсем печально.
Затычка на шаблонах для С++ для работы в распределенной среде тем не менее есть, только называется она не boost а ATL.
Вот когда в дотнете появяться дженерики тогда и будем посмотреть.
_>Что значит "принципиально компонентно-ориентированны"?
Значит что вызовы делегата из другого домена, процесса, машины типизированные и прозрачные.
Здравствуйте, AndrewVK, Вы писали:
_>>Делегат в .net не является прямым решением, это затычка, встроенная в компилятор: AVK>Ты не путай делегат и событие, это не одно и то же. event в шарпе это действительно фича компилятора, а вот делегат поддерживается рантаймом. Достаточно поглядеть в исходники ротора.
Конечно, поддерживается. И поддержка логично разделена на несколько частей — в bcl сам MulticastDelegate, в vm — магия, а компилятор генерит обертку над MulticastDelegate, подставляя туда параметры метода. И вдруг появляются generics, которые именно для того вроде и нужны, чтобы подставлять в шаблоны конкретные типы, но делегаты уже сделаны без них. Неортогональный дизайн
_>>Что значит "принципиально компонентно-ориентированны"? AVK>Значит что вызовы делегата из другого домена, процесса, машины типизированные и прозрачные.
Вызовы методов из другого домена, процесса, машины в дотнете тоже типизированные и прозрачные, но это не повод говорить, что в c++ нельзя создать полноценную замену методам.
Если не доходить до утверждений, что на c++ нет даже классов и методов, потому что нет рефлексии и сериализации, то чего из делегатов не хватает в сигналах?
Здравствуйте, desperado_gmbh, Вы писали:
_>>>Делегат в .net не является прямым решением, это затычка, встроенная в компилятор: AVK>>Ты не путай делегат и событие, это не одно и то же. event в шарпе это действительно фича компилятора, а вот делегат поддерживается рантаймом. Достаточно поглядеть в исходники ротора.
_>Конечно, поддерживается. И поддержка логично разделена на несколько частей — в bcl сам MulticastDelegate, в vm — магия, а компилятор генерит обертку над MulticastDelegate, подставляя туда параметры метода. И вдруг появляются generics, которые именно для того вроде и нужны, чтобы подставлять в шаблоны конкретные типы, но делегаты уже сделаны без них. Неортогональный дизайн
Еще ничего не извесно, а ты паникуешь. Шаблонов пока нет и спорить об это смысла нет, что это плохой дизайн.
На данный момент все сделано хорошо.
_>>>Что значит "принципиально компонентно-ориентированны"? AVK>>Значит что вызовы делегата из другого домена, процесса, машины типизированные и прозрачные.
_>Вызовы методов из другого домена, процесса, машины в дотнете тоже типизированные и прозрачные, но это не повод говорить, что в c++ нельзя создать полноценную замену методам.
Расскажи как это можно сделать по простому в С++. Всегда нужно писать чтото еще дополнительно и много. Или использовать COM\DCOM, что тоже не всегда просто.
Здравствуйте, desperado_gmbh, Вы писали:
_>Конечно, поддерживается. И поддержка логично разделена на несколько частей — в bcl сам MulticastDelegate, в vm — магия, а компилятор генерит обертку над MulticastDelegate, подставляя туда параметры метода. И вдруг появляются generics, которые именно для того вроде и нужны, чтобы подставлять в шаблоны конкретные типы, но делегаты уже сделаны без них. Неортогональный дизайн
Твой вариант?
_>Вызовы методов из другого домена, процесса, машины в дотнете тоже типизированные и прозрачные,
Естественно. А в чем проблема?
_>но это не повод говорить, что в c++ нельзя создать полноценную замену методам.
Делегат это замена скорее не методу, а интерфейсу.
Здравствуйте, AndrewVK, Вы писали:
_>>Конечно, поддерживается. И поддержка логично разделена на несколько частей — в bcl сам MulticastDelegate, в vm — магия, а компилятор генерит обертку над MulticastDelegate, подставляя туда параметры метода. И вдруг появляются generics, которые именно для того вроде и нужны, чтобы подставлять в шаблоны конкретные типы, но делегаты уже сделаны без них. Неортогональный дизайн AVK>Твой вариант?
В идеале класс Delegate вполне может оставаться магией, а MulticastDelegate должен быть нормальным классом, параметризованным типом метода. Сейчас, если хочется сделать свою обработку результатов вызовов зарегистрированных в делегате методов (например, не вываливаться после первого исключения или скомбинировать возвращаемые значения), приходится руками делать GetInvocationList и Invoke. Так как делегаты sealed, это приходится писать в отдельном методе. В бусте сигналы параметризуются обработчиком возвращаемых значений.
_>>Вызовы методов из другого домена, процесса, машины в дотнете тоже типизированные и прозрачные, AVK>Естественно. А в чем проблема?
Если признать, что делегаты в c++ неполноценны из-за отсутствия сериализации, то приходится признать, что классы и методы тоже неполноценны. Но тогда говорить вообще не о чем.
AVK>Делегат это замена скорее не методу, а интерфейсу.
Делегат — замена указателю на функцию или член класса.
Здравствуйте, desperado_gmbh, Вы писали:
AVK>>Делегат это замена скорее не методу, а интерфейсу.
_>Делегат — замена указателю на функцию или член класса.
Ты путаешь причину со следствием — указатель на функцию это уже следствие. Главная обязанность делегата — обеспечить типизированный колбек. Ровно то же можно сделать используя интерфейсы, что с успехом демонстрирует тот же свинг, да и в дотнете кое где встречается. Просто интерфейсы не очень удобны, поскольку приходится описывать отдельный класс. Вот для упрощения и вводится указатель на член класса или делегат. С такой точки зрения бустовский signal выглядит несколько ущербно, не согласен?
Здравствуйте, AndrewVK, Вы писали:
AVK>А как его должны дооценивать?
Короче пока вы с Владом не прочитаете Александреску я с вами на тему C++ vs C# разговаривать не буду ибо ваши знания о С++ очень поверхтносны.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
_>>Делегат — замена указателю на функцию или член класса. AVK>Ты путаешь причину со следствием — указатель на функцию это уже следствие. Главная обязанность делегата — обеспечить типизированный колбек. Ровно то же можно сделать используя интерфейсы, что с успехом демонстрирует тот же свинг, да и в дотнете кое где встречается.
Про нетипизированные колбеки говорить вообще не будем, потому что они не используются даже в с++. То, что для обратного вызова можно использовать несколько механизмов — хорошо, но интерфейс в c# синтаксически аналогичен базовому классу с чисто виртуальными методами в c++, а делегат в c# — некоей конструкции на основе указателя на член, называемой signal.
AVK>Просто интерфейсы не очень удобны, поскольку приходится описывать отдельный класс. Вот для упрощения и вводится указатель на член класса или делегат.
Указатели на члены беднее делегатов — они не multicast и не содержат внутри this для вызываемого метода. В билдере были нестандартные closure, но с приближением компиляторов к стандарту стал возможен и прямой путь — написать аналог делегата на стандартном c++, используя указатели на члены.
AVK>С такой точки зрения бустовский signal выглядит несколько ущербно, не согласен?
Как он может выглядеть ущербно, если выполняет ту же задачу и даже имеет похожий синтаксис?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alexkro, Вы писали:
A>>Спорный вопрос. C# generics ничего общего с шаблонами не имеют.
AVK>Ну насчет ничего общего это ты загнул, но действительно — дженерики и плюсовые шаблоны это не одно и то же.
A>>Пока что я для них одно применение вижу — типизированные контейнеры. Никакой новой парадигмы программирования они не откроют. Даже такая простая вещь как policy-based programming не станет возможна в C#.
AVK>Дженерики сделаны специально под дотнет. В них нет определенного функционала темплейтов, зато есть кое что, чего в темплейтах нет. Напиример темплейты в рантайме не видны, а дженерики видны.
Мне, вообщем-то, не очень интересны различия в runtime. А вот с точки зрения языков программирования, что есть в generics, чего в шаблонах нет?
AVK>В общем каждому свое. Что такое policy-based programming я не знаю, если объяснишь что ты под этим подразумеваешь то народ подскажет как подобное реализуется в дотнете.
Вот хороший пример.
AVK>И еще, писать на дотнете, так как ты это делал на С++ не стоит, ничего хорошего из этого не выдет. Другая идеология, другие паттерны.
Я думаю, ты имеешь в виду "на C# как на C++". Тогда согласен. Языки очень сильно различаются.
Здравствуйте, WolfHound, Вы писали:
AVK>>А как его должны дооценивать? WH>Короче пока вы с Владом не прочитаете Александреску я с вами на тему C++ vs C# разговаривать не буду ибо ваши знания о С++ очень поверхтносны.
, я был в восторге 
. Там, кстати, явно проглядывается лямбда-исчисление и функциональное программирование, по-моему. typedef — введение переменной, Func<A,B,C>::Result — вызов функции. Извращенно немножко, но похоже.
