Здравствуйте, WolfHound, Вы писали:
_>>Удивляюсь, как можно приводить абсолютно чудовищный код и утверждать, что это круто. WH>Я это привел к тому что: Делегаты в .NET не позволяют цеплять функции с другими сигнатурами даже если существует не явное приведение,
И это правильно. Типобезопасность рулит
WH>нельзя из делегата вернуть значение,
Кто сказал? А я не знал, возвращал. Теперь буду осторожнее.
M>А нет ли какой-нибудь толковой статьи на эту тему? Почему шаблоны так уж "откроют путь к совершенству"? Вроде вполне ограниченная технология на непредвзятый взгляд.
WH>Скорее не опытный ИМХО. Александреску читал?
Не читал. Это статья или толстая книга? Статью бы.
WH>boost потрошил?
Ха! Это получается заплатить вперёд, раньше чем увижу, нужны ли мне стулья.
VD>Делегаты делают то ради чего они и были созданы. Делают они это элегантно, но не шустро.
Я ещё немного поковырялся в Rotor. Значит, делегатский метод Invoke компилируется в x86-инструкции. В этих инструкциях проверка количества подцепленных функций (multicast/signlecast) и вызов.
То есть, это пара лишних indirection и одна проверка — для signle-cast.
Интерестно, что мультикасты в Rotor хранятся в linked list, а в Mono в массиве. Вроде бы в массиве лучше, ведь при создании объекта-делегата точно известно количество "кастов".
Кроме того, в Mono делегатский метод Invoke компилируется не в x86, а в IL — в отличие от Rotor.
Здравствуйте, Аноним, Вы писали:
А>Как считает общественность, реально ли появление в будущем, когда в C# будут введены шаблоны и другие средства, мощных библиотек, аналогов boost?
Шаблоны в С# вполне реальны я бы даже сказал что их поевление это гарантировано.
На МСДН есть стать про будашее C# так шаблоны собираються реализовать в самом ближайшем будощем работы над ними уже ведуться.
Здравствуйте, mihailik, Вы писали:
M>Не читал. Это статья или толстая книга? Статью бы.
Это книга А5 на 330 страниц. Не много но читать тяжело крышу сносит особенно по началу. http://www.moderncppdesign.com/
M>Ха! Это получается заплатить вперёд, раньше чем увижу, нужны ли мне стулья.
А до прочтения книги ты там ни чего не поймешь, да и после трудно.
... << RSDN@Home 1.0 beta 6a >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mikhail_T, Вы писали:
M_T>Шаблоны в С# вполне реальны я бы даже сказал что их поевление это гарантировано. M_T>На МСДН есть стать про будашее C# так шаблоны собираються реализовать в самом ближайшем будощем работы над ними уже ведуться.
Работы над ними уже проведены и шаблоны доступны в специальной версии ротора.
Здравствуйте, VladD2, Вы писали:
VD>Причем это решение еще и боле типбезопасно.
Какие-то странные у некоторых людей понятия о типобезопасности. Вот, скажем, implicit operator T() типобезопасен? А встроенное преобразование int в long типобезопасно? Почему мы можем вызвать метод с параметром типа long, передав ему int, но не можем присвоить delegate void d(int) свою void f(long)?
Здравствуйте, desperado_gmbh, Вы писали:
_>Какие-то странные у некоторых людей понятия о типобезопасности. Вот, скажем, implicit operator T() типобезопасен? А встроенное преобразование int в long типобезопасно? Почему мы можем вызвать метод с параметром типа long, передав ему int, но не можем присвоить delegate void d(int) свою void f(long)?
Потому что компилятор в состоянии увидеть, что передали параметр не того типа и сделать приведение. Для случая с делегатами это не так.
Здравствуйте, Lloyd, Вы писали:
_>>Какие-то странные у некоторых людей понятия о типобезопасности. Вот, скажем, implicit operator T() типобезопасен? А встроенное преобразование int в long типобезопасно? Почему мы можем вызвать метод с параметром типа long, передав ему int, но не можем присвоить delegate void d(int) свою void f(long)? L>Потому что компилятор в состоянии увидеть, что передали параметр не того типа и сделать приведение. Для случая с делегатами это не так.
Для случая с делегатами компилятор в состоянии сделать thunk, который сейчас приходится делать руками. В boost/signal это работает.
Здравствуйте, desperado_gmbh, Вы писали:
_>Для случая с делегатами компилятор в состоянии сделать thunk, который сейчас приходится делать руками. В boost/signal это работает.
C++ в этом плане более статичен. В Net-е можно создать делегат на метод, который в момент компиляции вовсе недоступен.
Здравствуйте, Lloyd, Вы писали:
_>>Для случая с делегатами компилятор в состоянии сделать thunk, который сейчас приходится делать руками. В boost/signal это работает. L>C++ в этом плане более статичен. В Net-е можно создать делегат на метод, который в момент компиляции вовсе недоступен.
Разница между delegate double op(double i, double f) и boost::signal<double(double,double)> op чисто синтаксическая, никакой большей статичности не наблюдается.
Ключевое место — op oper = new op(Add). Там все доступно.
Здравствуйте, desperado_gmbh, Вы писали:
_>Какие-то странные у некоторых людей понятия о типобезопасности.
Нормальные.
_> Вот, скажем, implicit operator T() типобезопасен? А встроенное преобразование int в long типобезопасно?
В С++ int и long синонимы (под 32-битными платформами). А вообще приведение безопастно если оно не может привести к переполнениям или обрезаниям. В дотнете приведения тоже работают. Ты можешь передать в делегат int вместо double-а. Но вот приводить один делегат к другому (имеющему другой список параметров) — это опасное действие. И правильно, что оно запрещено.
_> Почему мы можем вызвать метод с параметром типа long, передав ему int, но не можем присвоить delegate void d(int) свою void f(long)?
В отличии от С++ в дотнете без проблем код вызывающий делегаты из массива может находиться в другом исполнимом файле. А код запихивающий методы в массив в дурогом. И кроме контроля типов нет никакой гарантии, что в рантайме не "грохнет".
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, desperado_gmbh, Вы писали:
_>Для случая с делегатами компилятор в состоянии сделать thunk, который сейчас приходится делать руками. В boost/signal это работает.
Главная твоя проблема, что твой ум привык к примитивности С++ в котором компилятор всегда знает все. Дотнет же проектировался как компонентная среда. И обязан обеспечивать функциональность в отсуствии исходников. Плюсы я уже перечислял: компонентность, прозрачность для RPC и асинхронной обработки.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, desperado_gmbh, Вы писали:
_>Разница между delegate double op(double i, double f) и boost::signal<double(double,double)> op чисто синтаксическая, никакой большей статичности не наблюдается.
_>Ключевое место — op oper = new op(Add). Там все доступно.
Да? Ну, тогда создай нам такой же код но чтобы сигнал был объявлен и вызывлся в одной длл, а в другой к нему добавлялся метод (из другой же длл-и).
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
_>>Разница между delegate double op(double i, double f) и boost::signal<double(double,double)> op чисто синтаксическая, никакой большей статичности не наблюдается. _>>Ключевое место — op oper = new op(Add). Там все доступно. VD>Да? Ну, тогда создай нам такой же код но чтобы сигнал был объявлен и вызывлся в одной длл, а в другой к нему добавлялся метод (из другой же длл-и).
А в чем проблема-то, кроме того, что работа с dll вообще в c++ сделана криво? __declspec(dllexport) boost::signal<double(double,double)> op.
Здравствуйте, VladD2, Вы писали:
_>> Вот, скажем, implicit operator T() типобезопасен? А встроенное преобразование int в long типобезопасно? VD>В С++ int и long синонимы (под 32-битными платформами).
Я про c#, раз уж написал про implicit operator.
VD>А вообще приведение безопастно если оно не может привести к переполнениям или обрезаниям. В дотнете приведения тоже работают. Ты можешь передать в делегат int вместо double-а. Но вот приводить один делегат к другому (имеющему другой список параметров) — это опасное действие.
Безопасное действие при контравариантности типов параметров. Вон Form[] можно привевсти к Control[] — работает ковариантность. Здесь же наоборот — у нас есть метод void(Control) и мы хотим прицепить его к делегату void(Form). Где здесь опасность?
_>> Почему мы можем вызвать метод с параметром типа long, передав ему int, но не можем присвоить delegate void d(int) свою void f(long)? VD>В отличии от С++ в дотнете без проблем код вызывающий делегаты из массива может находиться в другом исполнимом файле. А код запихивающий методы в массив в дурогом. И кроме контроля типов нет никакой гарантии, что в рантайме не "грохнет".
Для понимания строки "op oper = new op(Add)" в этом самом другом файле компилятору c# необходимо знать тип делегата op и тип функции Add. Если они совпадают, все компилится. Если не совпадают, но имеют контравариантные типы, то сейчас происходит ошибка, и, чтобы ее избежать, нам надо руками писать переходник. Полностью типобезопасный, кстати. Почему бы эту рутинную работу не сделать компилятору за нас, если даже на стандартных плюсах можно соорудить типобезопасный signal, делающий то же самое?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AndrewVK, Вы писали:
AVK>Работы над ними уже проведены и шаблоны доступны в специальной версии ротора.
VD>Это не те шаблоны, что будут в дотнете. Все из МС в одни голос говорят, что ресерч ресерчем, а МС МС-ом.
Здравствуйте, desperado_gmbh, Вы писали:
_>Для понимания строки "op oper = new op(Add)" в этом самом другом файле компилятору c# необходимо знать тип делегата op и тип функции Add. Если они совпадают, все компилится. Если не совпадают, но имеют контравариантные типы, то сейчас происходит ошибка, и, чтобы ее избежать, нам надо руками писать переходник. Полностью типобезопасный, кстати. Почему бы эту рутинную работу не сделать компилятору за нас, если даже на стандартных плюсах можно соорудить типобезопасный signal, делающий то же самое?
А на кого возложить type casting при вызове такого делегата?
