Здравствуйте, desperado_gmbh, Вы писали:
_>Для понимания строки "op oper = new op(Add)" в этом самом другом файле компилятору c# необходимо знать тип делегата op и тип функции Add. Если они совпадают, все компилится. Если не совпадают, но имеют контравариантные типы, то сейчас происходит ошибка, и, чтобы ее избежать, нам надо руками писать переходник. Полностью типобезопасный, кстати. Почему бы эту рутинную работу не сделать компилятору за нас, если даже на стандартных плюсах можно соорудить типобезопасный signal, делающий то же самое?
Да на фиг это никому не нужно. Высасываешь пробему из поальца. Я на практике не разу не видил таких проблем. Если уж один раз возникнет такая проблема, то напишу переходник.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, desperado_gmbh, Вы писали:
_>А в чем проблема-то, кроме того, что работа с dll вообще в c++ сделана криво? __declspec(dllexport) boost::signal<double(double,double)> op.
Сделай, узнаешь.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это кстати одна из главных проблем С++ как языка.
Надо было написать сразу после прочтения трудно.
Например у меня уже почти не возникает вопросов как и почему.
ЗЫ А ты сам читал Александреску?
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
_>Если не совпадают, но имеют контравариантные типы, то сейчас происходит ошибка, и, чтобы ее избежать, нам надо руками писать переходник. Полностью типобезопасный, кстати. Почему бы эту рутинную работу не сделать компилятору за нас, AVK>А на кого возложить type casting при вызове такого делегата?
Я же говорю — на сгенерированный компилятором/джитом переходник. В бусте же как-то все работает.
Здравствуйте, VladD2, Вы писали:
VD>Да на фиг это никому не нужно. Высасываешь пробему из поальца. Я на практике не разу не видил таких проблем. Если уж один раз возникнет такая проблема, то напишу переходник.
Возможно. В форуме по с++ как-то утверждали, что делегаты нафиг никому не нужны.
Разговор начинался вообще с полезности шаблонов, signal — это просто пример. В c++ с помощью шаблонов удалось стандартными средствами реализовать делегаты, по возможностям не уступающие дотнетовским, исходя только из убогого указателя на член класса. С другой стороны, примеры в gyro/samples радуют, и многие вещи из stl/boost в .net не нужны вообще, особенно из-за сборки мусора (конкретнее, из-за отсутствия бардака с указателями/ссылками). Но пока непонятно, многие ли красивости и полезности, зависящие от отсутствующей в gyro явной специализации, перенесутся туда без потерь.
Здравствуйте, AndrewVK, Вы писали:
AVK>О том и речь куда этот переходник засунуть, чтобы потом рефлекшен всякую чешую не показывал.
MS уже смирился с этой чешуей — анонимные методы и, возможно, итераторы реализуются так же. К тому же только на c# до сих пор все было по принципу "что вижу, о том и пою", при компиляции других языков мусора и так хватает.
Здравствуйте, AndrewVK, Вы писали:
AVK>О том и речь куда этот переходник засунуть, чтобы потом рефлекшен всякую чешую не показывал.
Кстати, с появлением анонимных методов нелогичность становится очевидной:
delegate void op(Form ctl);
static void MyOp(Control f){}
op oper1 = new op(MyOp); // не компилится
op oper2 = new op(ctl){MyOp(ctl)}; // будет компилиться
Здравствуйте, Аноним, Вы писали:
А>Как считает общественность, реально ли появление в будущем, когда в C# будут введены шаблоны и другие средства, мощных библиотек, аналогов boost?
Шаблоны будут, как я понимаю. Не в том виде, как в С++, но все же чтото будет.
Boost имхо смысла нет вводить, тут другой дизайн.
Билиотеки появятся однозначно — от сторонних производителей, от MS и тд.
Они уже появляются.
Уже сейчас некоторые люди начинают портировать в .Net особо вкусные вещи.
Проще всего с COM. Тут в ряде случаев портировать и не надо.
Еще можно ожидать, что перфоманс повысится, может соптимизуют делегаты какие и тд.
Еще момент — .Net можно портировать куда попало.
Можно в КПК засунуть .Net. Не в том виде конечно, как под виндой, но все же можно.
Жаву же засунули в телефоны и КПК. .Net тож можно вкинуть.
Вопрос времени.
Здравствуйте, Plutonia Experiment, Вы писали:
А>>Как считает общественность, реально ли появление в будущем, когда в C# будут введены шаблоны и другие средства, мощных библиотек, аналогов boost?
PE>Шаблоны будут, как я понимаю. Не в том виде, как в С++, но все же чтото будет.
В общем то даже шаблонами их наверное называть не стоит, лучше generic types.
PE>Можно в КПК засунуть .Net. Не в том виде конечно, как под виндой, но все же можно.
Знаешь, тут один мой знакомый мой первый проект (сапер на дотнете) практически без правок запустил на PPC.
Здравствуйте, AndrewVK, Вы писали:
PE>>Можно в КПК засунуть .Net. Не в том виде конечно, как под виндой, но все же можно.
AVK>Знаешь, тут один мой знакомый мой первый проект (сапер на дотнете) практически без правок запустил на PPC.
А что такое PPC и кто cli mуда прикрутил, где бы это посмареть можно ?
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Знаешь, тут один мой знакомый мой первый проект (сапер на дотнете) практически без правок запустил на PPC.
PE>А что такое PPC
Здравствуйте, desperado_gmbh, Вы писали:
_>Возможно. В форуме по с++ как-то утверждали, что делегаты нафиг никому не нужны.
Это их проблемы.
_>Разговор начинался вообще с полезности шаблонов,
Про их полезность никто не спорит. Спор идет про виличие Буста и т.п.
_>signal — это просто пример.
Плохой пример. signal — это замазка проблемы. В С++ нет красивого ОО-решения для callback-ов (интерфейсы все же не удобны). Делегат является прямым и законченым решением. Шаблоны в этом случае в общем то не нужны. В С++ же они являются способом решить проблему.
У Шарпа тоже есть свои проблемы которые видимо тоже будут решать шаблонами. Но чем меньше будет таких замазок, тем более чистыми удобным останется язык. И уж точно никакой Буст не сравнится по количеству возможности с библиотекой фрэймворка.
_> В c++ с помощью шаблонов удалось стандартными средствами реализовать делегаты, по возможностям не уступающие дотнетовским,
Это не првада. И тебе уже это гворили. На С++ вообще нельзя создать 100%-ой замены делегатам. Делегаты принципиально компонентно-ориентированны. Их можно использовать без исходных кодов и в других процессах. К тому же на них можно реализовывать многопоточную обработку.
Ты же пытаешся строгую типизацию причислить к недостаткам технологии и на этом основании делашь выводы о их ущербности.
_> исходя только из убогого указателя на член класса. С другой стороны, примеры в gyro/samples радуют, и многие вещи из stl/boost в .net не нужны вообще,
Во-во. О том и речь. В дотнете от шаблонов нужен только полиморфизм типов и параметров.
_> особенно из-за сборки мусора (конкретнее, из-за отсутствия бардака с указателями/ссылками). Но пока непонятно, многие ли красивости и полезности, зависящие от отсутствующей в gyro явной специализации, перенесутся туда без потерь.
Я честно говря вижу только проблему которую возможно помогут обойти шалоны. Это как не странно отсуствие множественного наследования (МН). Мне лично МН нужно только для подключения к классам готовых реализаций. Будем надеяться, что шаблоны помогут обойти ее (за счет обратного наследования, ну, как ATL).
В остальном же я лично хотел бы видеть шаблоны в дотнете как средство напискания универсальных (generic) алгоритмов. МС похоже именно так и позиционируют шаблоны в дотнете (по крайней мере они выраженно подчеркивают название generic types, а не шабоны).
_>Хотя аналог boost/spirit
Возможно. Но предпочел бы более классическую запись. Самое главное что мне нарвится в Шарпе — это удивительная простота чтения исходников написанная другими. И очень охота чтобы это свойство не ушло в небытие.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Плохой пример. signal — это замазка проблемы. В С++ нет красивого ОО-решения для callback-ов (интерфейсы все же не удобны). Делегат является прямым и законченым решением. Шаблоны в этом случае в общем то не нужны. В С++ же они являются способом решить проблему.
Делегат в .net не является прямым решением, это затычка, встроенная в компилятор:
.class auto ansi sealed nested family AboutBoxDelegate
extends [mscorlib]System.MulticastDelegate
{
.method public hidebysig specialname rtspecialname
instance void .ctor(object 'object',
native int 'method') runtime managed
{
} // end of method AboutBoxDelegate::.ctor
.method public hidebysig virtual instance void
Invoke() runtime managed
{
} // end of method AboutBoxDelegate::Invoke
.method public hidebysig newslot virtual
instance class [mscorlib]System.IAsyncResult
BeginInvoke(class [mscorlib]System.AsyncCallback callback,
object 'object') runtime managed
{
} // end of method AboutBoxDelegate::BeginInvoke
.method public hidebysig newslot virtual
instance void EndInvoke(class [mscorlib]System.IAsyncResult result) runtime managed
{
} // end of method AboutBoxDelegate::EndInvoke
И для каждого делегата такая бодяга генерится заново именно из-за отсутствия шаблонов.
В отличие от делегатов, boost/signal — прямое и законченное решение на шаблонах (тут рассказали про глюки с dll, но это поправимо и естественно для такой молодой и некоммерческой библиотеки, как boost), не требующее специальной поддержки компилятора.
VD>И уж точно никакой Буст не сравнится по количеству возможности с библиотекой фрэймворка.
Это ортогональные вещи, одно другому только помогло бы.
VD>Это не првада. И тебе уже это гворили.
Про глюк в boost 1.30.0? Говорили, что багрепорт ушел.
VD>На С++ вообще нельзя создать 100%-ой замены делегатам. Делегаты принципиально компонентно-ориентированны. Их можно использовать без исходных кодов
Что значит "принципиально компонентно-ориентированны"? Для использования делегата необходимо на момент компиляции иметь доступ к типу делегата и переменной этого типа. При этих условиях на c++ можно использовать сигналы, не имея исходников чужой dll. Различия только в синтаксисе.
VD>и в других процессах. К тому же на них можно реализовывать многопоточную обработку.
Это достоинство не делегатов, а автоматического маршалинга параметров, работающего через рефлексию и атрибуты.
_>> исходя только из убогого указателя на член класса. С другой стороны, примеры в gyro/samples радуют, и многие вещи из stl/boost в .net не нужны вообще, VD>Во-во. О том и речь. В дотнете от шаблонов нужен только полиморфизм типов и параметров.
В бусте от шаблонов тоже нужен только полиморфизм типов и параметров
VD>Я честно говря вижу только проблему которую возможно помогут обойти шалоны. Это как не странно отсуствие множественного наследования (МН). Мне лично МН нужно только для подключения к классам готовых реализаций. Будем надеяться, что шаблоны помогут обойти ее (за счет обратного наследования, ну, как ATL).
Спешу расстроить. gyro/docs/generics/csharp.html:
The base class and base interfaces of a class may not be type parameters:
class Extend<V> : V { ... }
// Error, the base class may not be a
// type parameter
Здравствуйте, desperado_gmbh, Вы писали:
_>Делегат в .net не является прямым решением, это затычка, встроенная в компилятор:
_>
_>
Это не затычка. Не туда смотришь. Написано же — рантайм менеджед вместо IL менеджед
Кроме того, многие методы разных объектов в шарпе сделаны в нативном коде.
Таже болезнь и в жаве.
Так нельзя сравнивать. Эдак получится, что все, окромя С++ — затычки.
Здравствуйте, desperado_gmbh, Вы писали:
PE>>Так нельзя сравнивать. Эдак получится, что все, окромя С++ — затычки.
_>Далеко не всегда. Попытки сделать на C++ рефлексию или сборку мусора — тоже затычки.
В С++ другая парадигма. Для С++ нужен только компилятор.
Для шарпа этого уже недостаточно.
Потому и нежен рефлекшн и тд. Поскольку язык сделан максимально безопастным, делегаты сделаны в нем нативными средсвами.
