Re[9]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.06.03 21:46
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Для понимания строки "op oper = new op(Add)" в этом самом другом файле компилятору c# необходимо знать тип делегата op и тип функции Add. Если они совпадают, все компилится. Если не совпадают, но имеют контравариантные типы, то сейчас происходит ошибка, и, чтобы ее избежать, нам надо руками писать переходник. Полностью типобезопасный, кстати. Почему бы эту рутинную работу не сделать компилятору за нас, если даже на стандартных плюсах можно соорудить типобезопасный signal, делающий то же самое?


Да на фиг это никому не нужно. Высасываешь пробему из поальца. Я на практике не разу не видил таких проблем. Если уж один раз возникнет такая проблема, то напишу переходник.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.06.03 21:46
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>А в чем проблема-то, кроме того, что работа с dll вообще в c++ сделана криво? __declspec(dllexport) boost::signal<double(double,double)> op.


Сделай, узнаешь.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Будущее C#
От: WolfHound  
Дата: 28.06.03 09:33
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это кстати одна из главных проблем С++ как языка.

Надо было написать сразу после прочтения трудно.
Например у меня уже почти не возникает вопросов как и почему.

ЗЫ А ты сам читал Александреску?
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Будущее C#
От: WolfHound  
Дата: 28.06.03 09:33
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Сделай, узнаешь.

Это дефест boost'а, а не С++.
Багрепорт ушол.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 30.06.03 07:34
Оценка:
Здравствуйте, AndrewVK, Вы писали:

_>Если не совпадают, но имеют контравариантные типы, то сейчас происходит ошибка, и, чтобы ее избежать, нам надо руками писать переходник. Полностью типобезопасный, кстати. Почему бы эту рутинную работу не сделать компилятору за нас,

AVK>А на кого возложить type casting при вызове такого делегата?

Я же говорю — на сгенерированный компилятором/джитом переходник. В бусте же как-то все работает.
Re[11]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 30.06.03 07:48
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Я же говорю — на сгенерированный компилятором/джитом переходник.


О том и речь куда этот переходник засунуть, чтобы потом рефлекшен всякую чешую не показывал.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[10]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 30.06.03 07:48
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Да на фиг это никому не нужно. Высасываешь пробему из поальца. Я на практике не разу не видил таких проблем. Если уж один раз возникнет такая проблема, то напишу переходник.


Возможно. В форуме по с++ как-то утверждали, что делегаты нафиг никому не нужны.

Разговор начинался вообще с полезности шаблонов, signal — это просто пример. В c++ с помощью шаблонов удалось стандартными средствами реализовать делегаты, по возможностям не уступающие дотнетовским, исходя только из убогого указателя на член класса. С другой стороны, примеры в gyro/samples радуют, и многие вещи из stl/boost в .net не нужны вообще, особенно из-за сборки мусора (конкретнее, из-за отсутствия бардака с указателями/ссылками). Но пока непонятно, многие ли красивости и полезности, зависящие от отсутствующей в gyro явной специализации, перенесутся туда без потерь.

Хотя аналог boost/spirit
Автор: WolfHound
Дата: 31.05.03
, надеюсь, получится
Re[12]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 30.06.03 08:02
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>О том и речь куда этот переходник засунуть, чтобы потом рефлекшен всякую чешую не показывал.


MS уже смирился с этой чешуей — анонимные методы и, возможно, итераторы реализуются так же. К тому же только на c# до сих пор все было по принципу "что вижу, о том и пою", при компиляции других языков мусора и так хватает.
Re[12]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 30.06.03 08:19
Оценка: 14 (1)
Здравствуйте, AndrewVK, Вы писали:

AVK>О том и речь куда этот переходник засунуть, чтобы потом рефлекшен всякую чешую не показывал.


Кстати, с появлением анонимных методов нелогичность становится очевидной:

delegate void op(Form ctl);

static void MyOp(Control f){}

op oper1 = new op(MyOp); // не компилится
op oper2 = new op(ctl){MyOp(ctl)}; // будет компилиться
Re: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 30.06.03 13:02
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Как считает общественность, реально ли появление в будущем, когда в C# будут введены шаблоны и другие средства, мощных библиотек, аналогов boost?


Шаблоны будут, как я понимаю. Не в том виде, как в С++, но все же чтото будет.
Boost имхо смысла нет вводить, тут другой дизайн.
Билиотеки появятся однозначно — от сторонних производителей, от MS и тд.
Они уже появляются.
Уже сейчас некоторые люди начинают портировать в .Net особо вкусные вещи.
Проще всего с COM. Тут в ряде случаев портировать и не надо.
Еще можно ожидать, что перфоманс повысится, может соптимизуют делегаты какие и тд.
Еще момент — .Net можно портировать куда попало.
Можно в КПК засунуть .Net. Не в том виде конечно, как под виндой, но все же можно.
Жаву же засунули в телефоны и КПК. .Net тож можно вкинуть.
Вопрос времени.
Re[2]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 30.06.03 13:23
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

А>>Как считает общественность, реально ли появление в будущем, когда в C# будут введены шаблоны и другие средства, мощных библиотек, аналогов boost?


PE>Шаблоны будут, как я понимаю. Не в том виде, как в С++, но все же чтото будет.


В общем то даже шаблонами их наверное называть не стоит, лучше generic types.

PE>Можно в КПК засунуть .Net. Не в том виде конечно, как под виндой, но все же можно.


Знаешь, тут один мой знакомый мой первый проект (сапер на дотнете) практически без правок запустил на PPC.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[3]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 30.06.03 13:29
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>Можно в КПК засунуть .Net. Не в том виде конечно, как под виндой, но все же можно.


AVK>Знаешь, тут один мой знакомый мой первый проект (сапер на дотнете) практически без правок запустил на PPC.


А что такое PPC и кто cli mуда прикрутил, где бы это посмареть можно ?
Re[10]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.03 14:07
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>ЗЫ А ты сам читал Александреску?


Да я вроде и без него в С++ разбирался.

Вот только читать Шарп в разы приятнее.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 30.06.03 14:13
Оценка: 21 (1)
Здравствуйте, Plutonia Experiment, Вы писали:

AVK>>Знаешь, тут один мой знакомый мой первый проект (сапер на дотнете) практически без правок запустил на PPC.


PE>А что такое PPC


PocketPC

PE>и кто cli mуда прикрутил,


Microsoft

PE>где бы это посмареть можно ?


www.microsoft.com, Compact Framework
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[11]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.03 14:26
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Возможно. В форуме по с++ как-то утверждали, что делегаты нафиг никому не нужны.


Это их проблемы.

_>Разговор начинался вообще с полезности шаблонов,


Про их полезность никто не спорит. Спор идет про виличие Буста и т.п.

_>signal — это просто пример.


Плохой пример. signal — это замазка проблемы. В С++ нет красивого ОО-решения для callback-ов (интерфейсы все же не удобны). Делегат является прямым и законченым решением. Шаблоны в этом случае в общем то не нужны. В С++ же они являются способом решить проблему.

У Шарпа тоже есть свои проблемы которые видимо тоже будут решать шаблонами. Но чем меньше будет таких замазок, тем более чистыми удобным останется язык. И уж точно никакой Буст не сравнится по количеству возможности с библиотекой фрэймворка.

_> В c++ с помощью шаблонов удалось стандартными средствами реализовать делегаты, по возможностям не уступающие дотнетовским,


Это не првада. И тебе уже это гворили. На С++ вообще нельзя создать 100%-ой замены делегатам. Делегаты принципиально компонентно-ориентированны. Их можно использовать без исходных кодов и в других процессах. К тому же на них можно реализовывать многопоточную обработку.

Ты же пытаешся строгую типизацию причислить к недостаткам технологии и на этом основании делашь выводы о их ущербности.

_> исходя только из убогого указателя на член класса. С другой стороны, примеры в gyro/samples радуют, и многие вещи из stl/boost в .net не нужны вообще,


Во-во. О том и речь. В дотнете от шаблонов нужен только полиморфизм типов и параметров.

_> особенно из-за сборки мусора (конкретнее, из-за отсутствия бардака с указателями/ссылками). Но пока непонятно, многие ли красивости и полезности, зависящие от отсутствующей в gyro явной специализации, перенесутся туда без потерь.


Я честно говря вижу только проблему которую возможно помогут обойти шалоны. Это как не странно отсуствие множественного наследования (МН). Мне лично МН нужно только для подключения к классам готовых реализаций. Будем надеяться, что шаблоны помогут обойти ее (за счет обратного наследования, ну, как ATL).

В остальном же я лично хотел бы видеть шаблоны в дотнете как средство напискания универсальных (generic) алгоритмов. МС похоже именно так и позиционируют шаблоны в дотнете (по крайней мере они выраженно подчеркивают название generic types, а не шабоны).

_>Хотя аналог boost/spirit
Автор: WolfHound
Дата: 31.05.03
, надеюсь, получится


Возможно. Но предпочел бы более классическую запись. Самое главное что мне нарвится в Шарпе — это удивительная простота чтения исходников написанная другими. И очень охота чтобы это свойство не ушло в небытие.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.03 14:26
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Сделай, узнаешь.

WH>Это дефест boost'а, а не С++.
WH>Багрепорт ушол.

А. Ну-ну. Интересно как я погу знать о таких вещах даже не пробовав?
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 30.06.03 14:51
Оценка:
Здравствуйте, 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
Re[13]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 30.06.03 15:02
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Делегат в .net не является прямым решением, это затычка, встроенная в компилятор:


_>

_>


Это не затычка. Не туда смотришь. Написано же — рантайм менеджед вместо IL менеджед
Кроме того, многие методы разных объектов в шарпе сделаны в нативном коде.
Таже болезнь и в жаве.
Так нельзя сравнивать. Эдак получится, что все, окромя С++ — затычки.
Re[14]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 30.06.03 15:12
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Так нельзя сравнивать. Эдак получится, что все, окромя С++ — затычки.


Далеко не всегда. Попытки сделать на C++ рефлексию или сборку мусора — тоже затычки.
Re[15]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 30.06.03 15:17
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

PE>>Так нельзя сравнивать. Эдак получится, что все, окромя С++ — затычки.


_>Далеко не всегда. Попытки сделать на C++ рефлексию или сборку мусора — тоже затычки.


В С++ другая парадигма. Для С++ нужен только компилятор.
Для шарпа этого уже недостаточно.

Потому и нежен рефлекшн и тд. Поскольку язык сделан максимально безопастным, делегаты сделаны в нем нативными средсвами.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.