Здравствуйте, mrhru, Вы писали:
M>Можно узнать, в чём же их принципиальное различие?
В подходах и списке решамых задач. С помощью полиморфизма нельзя достичь типобезопастности. Все проверки будет в рантайме.
M>Ведь дженерик работая с переданным типом, обращается к вполне определённому подмножеству его методов/свойств. Назовём это подмножество интерфейсом, и скажем, что переданный тип реализует этот интефейс. А теперь передадим в бывший дженерик, а теперь обычный класс, это интерфейс — и получим то же самое. Не так ли? Ну да, теперь надо этот интерфейс ещё и описать. Но вряд ли это принципиальное отличие. M>Тогда что же?
1. Дженирики ни как не завязаны ОО-концепции позволяя создавать чистые алогоритмы.
2. Дженирики позволяют оперировать с рипами разных размеров.
3. Дженерики обеспечивают дипобезопастность на этапе компиляции.
4. Дженирики позволяют создавать специализации интерфейсов, и т.п. извраты позоляющие существнно ускорить работу конечного приложения.
M>PS. Естественно, не имею ввиду простые типы. Использование шаблонов на них — действительно удобно.
Структуры простые типы?
Короче, полиморфизм и обобщенное программирование позволяют решать одни и те же задачи. Но по разному. И с совершенно разной эффектиностью.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Serginio1, Вы писали:
S> Это почему. На самом деле объяви я их виртуальными с пустой реализацией все нормально??? И зачем мне общие поля переопределять в каждом наследнике????
Честно говоря объяснять концепции ООП борцам за ООП довольно смешно.
S> Ты немного ошибаешься. Это единственно верный дизайн. А по поводу интерфейсов мне так никто и не ответил на заданный вопрос S>http://www.rsdn.ru/Forum/Message.aspx?mid=410955&only=1
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alexkro, Вы писали:
A>>А так-же будет поддерживаться смесь templates & generics. Например:
AVK>Ты путаешь МС++ и С++/CLI. Это совершенно разные языки.
Начнем с того, что так называемого MC++ в природе нет. Есть managed extensions. А в Whidbey они будут интегрированы в язык настолько плотно, что называть это managed extensions уже не имеет смысла. Это уже C++ для CLR.
Кстати, Whidbey VC++ будет реализовывать очень большую часть C++/CLI стандарта, а Orcas — весь. Посмотри PDC'шные слайды Саттера по этому поводу.
Здравствуйте, alexkro, Вы писали:
AVK>>Ты путаешь МС++ и С++/CLI. Это совершенно разные языки.
A>Начнем с того, что так называемого MC++ в природе нет. Есть managed extensions.
Я в курсе. Я так же в курсе что под сокращением МС++ большинство подразумевают С++ with managed extensions.
A>А в Whidbey они будут интегрированы в язык настолько плотно, что называть это managed extensions уже не имеет смысла.
В видби кроме поддержки новых фич CLR кардинальных изменений у МС++ не будет.
A> Это уже C++ для CLR.
Тем не менее название осталось прежним.
A>Кстати, Whidbey VC++ будет реализовывать очень большую часть C++/CLI стандарта,
Практически ничего не реализует де-факто и вряд ли что существенно изменится.
A>а Orcas — весь. Посмотри PDC'шные слайды Саттера по этому поводу.
Зачем мне PDC-шные слайды если у меня PDC-шный видби есть.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Актуальный код это когда компилятор уже знает расбросал код на составляющие при и ясны связи и типы в отличие от шаблонов где этот этап происходит на этапе компиляции.
VD>Понятнее не стало.
Актуальный код для компилятора в момент редактирования кода. Проверка синтаксиса, подсказки по типам итд.
S>> Громоздкость заключается в том, что для каждого класса генерится свой код.
VD>Тебя то это как трогает? Дженирики тоже для каждого вэлью-типа свой код генерируют. Только в рантайме. Ну, и что? Какое это имеет отношение к громоздкости кода? Здается мне, что ты плохо знаешь синтаксис шаблонов. Они по сути мало отличаются.
Генерится может код работающий только с эти валью типом, но т.к. в самом дженерике напрямую ты можешь только присвоить значение соотвествующего значения или переместить т.е. работа на основании размера тип, то все остальные операции в дженерике связаны только с размером типа (заталкивание в стек, Move, итд). И дополнительного кода может быть очень мало. Это уже зависит от конечной реализации. S>> И при создание шаблона S>>нужно ориентироваться на конечный исходный код. Хотя это и не проблема при небольших классах но на огромных это может приводить к непредсказуемым ошыбкам.
VD>Какой конечный? Нет никакого "конечного" кода. Есть просто исходный код. Он и в Африке исходным кодом будет.
Исходный текст шаблона это не исходный текст готовый для его перевода в Ассемблер.
Все завязываю я с шаблонами. На вкус и цвет товарищей Net.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Шаблоны тем или иным способом реализуются и в других языках через подстановку типа или Copy-Paste_Replace. Т.К. в С# есть перегрузка операторов то ручная реализация шаблонов достаточно тривиальная задача через исходный код, но для того чтобы не делать лишних телодвижений было бы неплохо иметь генератор исходников на основании шаблонов на уровне компилятора.
VD>Раз тривиальная, то попробуй сделай.
Чем и занимаюсь долгое время. На основании уже созданного класса с простой подменой. Единственно что в Delphi нет перегрузки операторов, а так это вообще тривиальная задача.
А вот если они внедрят в Delphi.Net то никакого премущесва от сишных шаблонов не останется и следа. Хотя тоже можно делать и C#.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Это почему. На самом деле объяви я их виртуальными с пустой реализацией все нормально??? И зачем мне общие поля переопределять в каждом наследнике????
VD>Честно говоря объяснять концепции ООП борцам за ООП довольно смешно.
S>> Ты немного ошибаешься. Это единственно верный дизайн. А по поводу интерфейсов мне так никто и не ответил на заданный вопрос S>>http://www.rsdn.ru/Forum/Message.aspx?mid=410955&only=1
Тогда все дизайны в Delphi и Net ошибочны. Возьмем для примера Stream. А уж других кастомных классов огромное множество, где в базовом классе практически реализована базовая функциональность, но расчитана на перекрытие, реализации абстрактных методов и расширение функциональности в наследниках. А директива abstract говорит лишь о том, что невозможно создать экземпляр этого класса. Кстати ООП у Дельфистов в крови, поэтому переход на C# и Net дается бескровно, особенно гляда на нетовские коипоненты где это практически полные аналоги дельфевых только с расширенными возможностями.
Интерфейсы нужны тогда, когда нужна дополнительная функциональность невозможная при наследовании от базового класса (некий аналог множественного наследования но реализованный на VMT), и работа с интерфейсами это несколько другой подход нежели наследование.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Актуальный код для компилятора в момент редактирования кода. Проверка синтаксиса, подсказки по типам итд.
Значит ты еще и редактор к ООП припахал.
Комплит ворд это хошо, но к ООП он отношения не имеет.
S> Генерится может код работающий только с эти валью типом, но т.к. в самом дженерике напрямую ты можешь только присвоить значение соотвествующего значения или переместить т.е. работа на основании размера тип, то все остальные операции в дженерике связаны только с размером типа (заталкивание в стек, Move, итд). И дополнительного кода может быть очень мало. Это уже зависит от конечной реализации.
Хрен. Для каждого вэлью типа генерируется всой класс (код). А вот в С++ как раз линкер выкидывает схожие классы подменяя их единой реализацией. Так что выигрыш в размере исполняемого файла можно получить только если дженерик/шаблон используется в разных модулях.
Ну, и главное не нужно подменять понятия. Громоздкость кода может иметь отношение только коду и его объему/читабельности. А в этом аспекте шаблоны мало отличимы от дженириков.
Что же касается размеров модулей... фигня все это. С++-ые длл-ки и ехе-шиники стройны как тополя. Смерть от ожирения им в ближайшее время не грозит. А вот скорость нужна всегда и везде. И тут шаблоны рулят. Будем надяеться, что к выходу релиза дотнета 1.2 он будет соотвествовать спецификации на тот же Шарп 2.0 и при вызовах методов интерфейсов у вэлью-типов не будет произход боксинга (как сейчас). Ну и будем надеяться, что при этом джит сможет инлайнить вызовы таких псевдо-интерфейсов, что позволит получить производительность близкую к той, что достижима на VC 7+.
S> Исходный текст шаблона это не исходный текст готовый для его перевода в Ассемблер.
Тебч что кто-то что-то в ассемблер в ручную заставляет прееводить? Или ты всерьез считашь, что компилятор С++ генерирует промежуточные исходники при компиляции шаблонов? Тогда ты глубоко заблуждаешся.
И вообще, зачем притягивать что-то за уши? Для программиста есть только одни исходники и всем глубого фиолетово как и когда компилятор переводит шаблоны в машинный код. Всех интересует результат. А результатк таков... На стороне шаблонов:
1. Гибкость.
2. Производительность.
На стороне дженириков:
1. Поддрежка технологии Интели-сенс.
2. Распростронение в виде промежуточного кода, а стло быть, возможность использования без наличия исходного кода.
Безспорно и первое и второе достоинство дженириков приятно. Но ключевыми достоинствами обобщенного программироания являются типобезопастность и производительность. А стало быть у С++-ных шаблонов есть некоторый перевес так как производительность у кода созданного с их помощью (при прочих равных) выше.
S> Все завязываю я с шаблонами. На вкус и цвет товарищей Net.
Ты лучше с фанатизмом завязывай. Нужно трезво оценивать реальность.
Дженирики это очень полезный шаг. Но по своим возможностям они пока что уступают шаблонам С++.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Serginio1, Вы писали:
S> Чем и занимаюсь долгое время. На основании уже созданного класса с простой подменой. Единственно что в Delphi нет перегрузки операторов, а так это вообще тривиальная задача. S> А вот если они внедрят в Delphi.Net то никакого премущесва от сишных шаблонов не останется и следа. Хотя тоже можно делать и C#.
Это говорит только об одно. Ты вообще не представляешь себе возможностей С++-ных шаблонов. Увы разговор с тобой бесполезен.
То о чем ты говоришь в С++ можно сделать с помшью макросов. Возможности же шаблонов простыми реплэйсами не покрываются.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Serginio1, Вы писали:
S> Тогда все дизайны в Delphi и Net ошибочны.
Кое какие да. Обобщать бы я не стал.
S> Возьмем для примера Stream.
Ага возьми. Открой его дизасемблером и убедись, что он является базовой реализацией. В нем добрая половина методов имеет реализацию.
С другой стороны то, что нет IStream — это явный промох дизайна. Что поделаешь? Драли с ранних версий Явы.
Наличие IStream позволило бы другим делать реализации стрима координально отличные от Stream. Например, можно было бы Сделать обертку над КОМ-овским IStream-ом.
S> А уж других кастомных классов огромное множество, где в базовом классе практически реализована базовая функциональность, но расчитана на перекрытие,
Вот прочти эти строки еще раз... В них суть. Интерфейс — это чистая абстракция. В то время как абстрактный класс — это базовая реализация.
S> Интерфейсы нужны тогда, когда нужна дополнительная функциональность невозможная при наследовании от базового класса (некий аналог множественного наследования но реализованный на VMT), и работа с интерфейсами это несколько другой подход нежели наследование.
Советую почитать какую-нибудь классику по ОО-дизайну и проектированию.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alexkro, Вы писали:
A>>А так-же будет поддерживаться смесь templates & generics. Например:
AVK>Ты путаешь МС++ и С++/CLI. Это совершенно разные языки.
Есть слухи что в Видби таки включат это дело. Уже сейчас если написать в коде:
String ^ str = new String();
то компилятор орет:
Новый стиль "^" нельзя испосльзовать с ключем /clr:oldStyle.
Так что возможно, что или он уже поддерживается (не документированной опцией), или будет поддерживаться в релизе.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alexkro, Вы писали:
A>Начнем с того, что так называемого MC++ в природе нет. Есть managed extensions.
Это демагогия.
A> А в Whidbey они будут интегрированы в язык настолько плотно, что называть это managed extensions уже не имеет смысла. Это уже C++ для CLR.
Скажу честно, что это уже не С++. Это уже микс. Причем этот микс как полезен, так и вреден. С одной стороны он упрощает программирование. Но с другой он скрывает реальные действия. Причем делается это нехилыми обертками. Это приведет к значительной потере произовдительности при импользовании нэйтив/цлр-переходов. Старый МС++ показывал все действия так как они будет выглядеть в рельности. Даже боксинг итот был виден. В то же время МС++ останется языком корректный код на котором можно получать только используя кучу код-патернов. Причем кроме как в интеропе, и использовнии унасленованного С/С++-ного кода, реальных приеимуществ в МС++ получить будет нельзя. Единствнное приятное новшество которого не будет в других языках — это детерминированная финализация. Но и она будет всего лишь скрытием патерна IDisposable. МС++ бдет герерить прокси для менеджед-классов хранимых в анменеджед-коде и наоборот.
Так что приемуществ у МС++ по сравнению с Шарпом или Васиком в общем-то не будет.
A>Кстати, Whidbey VC++ будет реализовывать очень большую часть C++/CLI стандарта, а Orcas — весь. Посмотри PDC'шные слайды Саттера по этому поводу.
Пока что компилятор не дает их использовать вообще. По крайней мере не ясно как это сделать. Но намеки есть. По крайней мере компилятор осмысленно ругается на синтаксис описанный на PDC-шных слайдах.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Пока что компилятор не дает их использовать вообще. По крайней мере не ясно как это сделать. Но намеки есть. По крайней мере компилятор осмысленно ругается на синтаксис описанный на PDC-шных слайдах.
Попробуй /d1clrnewSyntax. Может поменьше ругаться будет.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alexkro, Вы писали:
A>>Попробуй /d1clrnewSyntax. Может поменьше ругаться будет.
VD> Шайтан! Как узнал?
VD> PS
VD> Вот только стало ясно, что из обещанных вкусностей по сути есть только ^. А что с нее толку?
Это-же только альфа. Жди бету, там почти все будет. А пока можно спек почитать.
Здравствуйте, LaFlour, Вы писали:
LF>Насколько правила женериков для С++ отличаются/подходят к #-вым? LF>Ну синтаксис и прочее что писал Алексадреску и Джосуттис, насколько они адекватны в свете #вых женериков?
Неплохое сравнение templates & generics в C++ приведено в блоге Брандон Брейя (Brandon Bray).
Кстати, там-же немножко про STL.NET (пресловутый stdcli::).
Здравствуйте, alexkro, Вы писали:
AVK>>Зачем мне PDC-шные слайды если у меня PDC-шный видби есть.
A>А за тем, что в Whidbey PDC еще нет тех изменений, которые будут в релизе Whidbey C++.
Очень сомнительно. Тем более что про дату выхода C++/CLI где то упоминалось что в мае 2004 только появиться первая альфа. В это время у Видби во всю будет идти бета-тестирование, а следовательно никаких серьезных изменений не будет.
Здравствуйте, VladD2, Вы писали:
VD>Ага возьми. Открой его дизасемблером и убедись, что он является базовой реализацией. В нем добрая половина методов имеет реализацию.
VD>С другой стороны то, что нет IStream — это явный промох дизайна. Что поделаешь? Драли с ранних версий Явы.
VD>Наличие IStream позволило бы другим делать реализации стрима координально отличные от Stream.
Тебе и сейчас ничего не мешает. В базовом Stream реализованы только асинхронное чтение/запись и ReadByte/WriteByte, которые по сути просто обертки над Read/Write.
VD>Например, можно было бы Сделать обертку над КОМ-овским IStream-ом.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Тогда все дизайны в Delphi и Net ошибочны.
VD>Кое какие да. Обобщать бы я не стал.
S>> Возьмем для примера Stream.
VD>Ага возьми. Открой его дизасемблером и убедись, что он является базовой реализацией. В нем добрая половина методов имеет реализацию.
А зачем дизасемблером в роторе есть исходники и реализуют он только ассинхронные вызовы. VD>С другой стороны то, что нет IStream — это явный промох дизайна. Что поделаешь? Драли с ранних версий Явы.
Если объект создан от Stream то передавай его целиком. Если же нужна другая функциональность то просто внедряется класс наследник от Stream и делается импликит на него. VD>Наличие IStream позволило бы другим делать реализации стрима координально отличные от Stream. Например, можно было бы Сделать обертку над КОМ-овским IStream-ом.
Ком это прошлый век и не стоит на него оборачиваться, а для совместимости с ним в Delphi например есть классы хэлперы TStreamAdapter и TOleStream. S>> А уж других кастомных классов огромное множество, где в базовом классе практически реализована базовая функциональность, но расчитана на перекрытие,
VD>Вот прочти эти строки еще раз... В них суть. Интерфейс — это чистая абстракция. В то время как абстрактный класс — это базовая реализация.
Еще раз повторю интерфейсы нужны только для расширения функциональности где простого наследования не хватает. Представь если бы все наследники от Component были реализованы чере IComponent. S>> Интерфейсы нужны тогда, когда нужна дополнительная функциональность невозможная при наследовании от базового класса (некий аналог множественного наследования но реализованный на VMT), и работа с интерфейсами это несколько другой подход нежели наследование.
VD>Советую почитать какую-нибудь классику по ОО-дизайну и проектированию.
Большое спасибо за совет. Тот же Рихтер говорит, что абстрактные классы предпочтительней там где есть явное наследование и предпочтитель интерфейсы где это невозможно.
и солнце б утром не вставало, когда бы не было меня
Шайтан! Как узнал?
