Здравствуйте, Akzhan, Вы писали:
A>Здравствуйте, Lloyd, Вы писали:
L>>Повторяю для тех, кто в танке: Реализация классом интерфейса == Наследование интерфейса. L>>Это общепринятый термин и не надо пытаться сопоставлять его семантику и этимологию. Этимология не обязана соответствовать семантике.
A>Абсолютно не соответствует истине. A>Реализация классом интерфейса — это "реализация интерфейса" или "выполнение контракта". A>Никакого отношения к "наследованию реализации" не имеет, кроме как схожести механизмов реализации "наследования" и "реализации".
Акжан, вы недостаточно внимательно прочитали мое послание. Я же явно указал, что семантика и этимолигия слова(термина) не обязаны соотвветствовать друг другу. Вы же взяли и свалили их в одну кучу.
Поясню, что я имею в виду.
И "наследование реализации" и "наследование интерфейса"-- суть термины. У них есть вполне конкретное значение.
Первое -- понятно что такое.
Второе -- это то, что многие (в том числе и вы) называют "реализацией интерфейса" или "выполнением контракта".
Увидив в этих двух теминах общее слове "наследование" (этимология). Вы с радостью набросились на него и начали доказывать, что наследование реализации и реализация интерфейса -- разные вещи (семантика). С тем, что это разные вещи, я абсолютно согласем.
Ваша ошибка была в том, что вы не восприняли эти термины именно как термины, а пытались из их "звучания" выудить какой-то дополнительный смысл. Не всегода стоит делать это. Иногда стоит и почитать книжки, в которых эти термины объяснялись.
A>Но ни один грамотный человек, например, не поставит знак равенства между "отношением генерализации" и "ассоциацией 1:1", хотя реализуются эти механизмы в физической модели часто одинаково.
A>Точно также и наследование с реализацией. Реализация интерфейса фактически сводится к таблицам виртуальных методов, но разница есть, и она концептуальная.
Кто бы спорил.
Re: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, flatch, Вы писали:
F>Планирует ли MS в новой версии .NET добавить в C# поддержку шаблонов и множественного наследования классов? F>Или, может, в будущем они планируют? F>Кто что слышал по этому поводу, поделитесь плиз.
Вопрос как мне кажется не в том будут ли шаблоны, а в том нужны ли они. На мой взгляд шаблоны — ошибочная ветка развития ООП и в .NET не нужны. Абсолютно любую задачу, рещаемую при помощи шаблонов можно решить более красиво и более просто.
PS: Помидорами не кидать. Основываюсь на своём опыте разработки и применении шаблонов.
V>Я бы сказал, что это операция композиции интерфейсов. Наследование несет определенную смысловую нагрузку, связянную с V>приобретением данных/кода предка.
То, о чем вы говорите, называется наследованием реализации. То о чем говорит AndrewVK -- наследование интерфейса. И то, и другое -- наследование.
Re[2]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, Tom, Вы писали:
Tom>Вопрос как мне кажется не в том будут ли шаблоны, а в том нужны ли они. На мой взгляд шаблоны — ошибочная ветка развития ООП и в .NET не нужны. Абсолютно любую задачу, рещаемую при помощи шаблонов можно решить более красиво и более просто.
В общем то правильно, вот только перфоманс, поганка эдакая, всю малину портит. А так конечно без них проще.
Просто имхо шаблоны не очень гибкая вещь, варианты параметров весьма ограничены. Я бы предпочел встроенную в код полномасштабную поддержку кодогенерации а не затычки ввиде шаблонов.
Здравствуйте, Tom, Вы писали:
Tom>В общем давай разбираться про какие абстракции мы говорим. Возьмём твой пример с IList<T>, только переименуем в Foo. Да действительно в данном случае не плохо будет если параметром можно будет пихать тип хранимых данных. Но если шаблон будет типа Foo<Class T> это будет означать явную зависимость класса от интерфейса класса, передаваемого в качестве параметра.
Это без разницы будет там слово class или нет. А то что шаблон будет строиться на базе интерфейса типа данных T — это большое приимущетсво, так как все проверки можно будет сделать дизайнтайме. И тебе просто не дадут скомпилировать Foo<Some> если Some не поддерживает нужной для Foo функциональности.
Т.е что бы передать класс в качестве парамемтра, я буду должен реализовать набор определённых, пусть и не виртуальных, методов, что называется интерфейс. Замечаешь ключевое слово Эту же задачу я мог бы решить следующим образом.
Tom>1. Обьявить интерфейс. Tom>2. В классе Foo сделать свойство или метод, принимающий необходимый интерфейс. Tom>3. Реализовать данный интерфейс и передать классу Foo
Нет не сможешь. Нано или поздно ты скатишся на поля/параметры типа object и как следствие потерю производительности и проблемы с контролем типов (который придется выполнять в рантайме и вручную).
Tom>Итак какие мы получаем выгоды. Прозрачность кода, так как интерфейс описан и связывание происходит в рантайм. Недостатки — так как связывание идёт в рантайм то ухудшается производительностью. Насколько этот недостаток критичен — это вопрос конкретной задачи.
Ну выводы сделанные на неверных предпосылках...
Так что лучше не надо философии вот тебе обратно обычный IList и его индексатор:
Попробуй использовать свой интерфейс.
Tom>Выводы Tom>На данном этапе я для себя уяснил, что: простой тип, структура, Value Class в качестве параметра шаблона — хорошо, так как шаблон улучшает алгоритм, делая его не зависимым от типа используемых данных. Хотя на самом деле наверное хорошо — это только простой тип, так как и структура и Value Class вносит зависимость от интеорфейса в большинстве случаев.
Глупость. Зависимость от интерфейса будет всегда. Действи типа "=", "==", "+" и т.п. — это тоже интерфейс. Весь кайф шаблонов, в том что ты можешь пользоваться им наиболее эффективно и не прибегать к полиморфизму. Более того шаблоны дают некий упрощенных статический полиморфизм, который намного более безопасен и эффективен.
Tom>Класс с определённой функциональностью — плохо, так как вносит зависимость от интерфейса, явно не определяя этого интерфейса, что приводит к осложненим при отладке.
Полнейшая ерунда. Никаких осложнений при отладке нет. Это проверено тем же С++. На заре С++ были проблемы с отладчиками, но сегодня таких проблем нет и шалблоны прекрасно отлаживаются.
Никто не мещает подставлять в качестве значения шаблона интерфейс но если этот интерфейс не шаблонный, это не имеет никакого смысла. Так как в этом случае можно обойтись и без шаблона. Зато если интерфейс тоже шаблонный, то все становится еще гибче:
class Foo<T>
{
IBar<T> bar;
};
Tom>Я не знаю, что нового собирается M$ привнести в шаблоны, но будем надеятся что это как сказал Влад только улучшит перфоманс и простоту суппорта и отладки, чего не было с старых шаблонах.
Про то чего небыло. Ты сам себе придумал. Шаблоны в С++ сложны настолько насколько сложен сам С++. В Шарпе они хотят еще болшее упрастить синтаксис. И я думаю, что главное чтобы в погоне за этими упрощениями они не удалили полезных свойств шаблонов.
Например, уже (пхоже) удалена возможность обявлять шаблонные методы. Поэтому в Шарпе если нужно всего лишь объявить шаблонный метод придется делать шаблонный класс и объявлять в нем статический метод. Что усложнит синтаксис. Вот это плохо.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>И еще, об этом речь недавно велась, но все же. Реализация классом интерфейса ни в коем случае наследованием не является.
Повторяю для тех, кто в танке: Реализация классом интерфейса == Наследование интерфейса.
Это общепринятый термин и не надо пытаться сопоставлять его семантику и этимологию. Этимология не обязана соответствовать семантике.
Re[5]: Будут ли шаблоны и множественное наследование в CLR?
VD>2. МС к ней отношение имее очень отдаленная. Это скорее HP.
Пусть будет HP. Не всегда же камни кидать в M$ сторону
Tom>>А если на них ещё навёрнуто 5-6 слоёв то как ???
VD>Слышал про такое понятие — абстракция? Надеюсь, да.
Неа. А это что такое ?
VD>Так вот если абстракция хорошо продумана и воплощена шаблоном, то пользоваться ею очень прото и удобно.
В общем давай разбираться про какие абстракции мы говорим. Возьмём твой пример с IList<T>, только переименуем в Foo. Да действительно в данном случае не плохо будет если параметром можно будет пихать тип хранимых данных. Но если шаблон будет типа Foo<Class T> это будет означать явную зависимость класса от интерфейса класса, передаваемого в качестве параметра. Т.е что бы передать класс в качестве парамемтра, я буду должен реализовать набор определённых, пусть и не виртуальных, методов, что называется интерфейс. Замечаешь ключевое слово Эту же задачу я мог бы решить следующим образом.
1. Обьявить интерфейс.
2. В классе Foo сделать свойство или метод, принимающий необходимый интерфейс.
3. Реализовать данный интерфейс и передать классу Foo
Итак какие мы получаем выгоды. Прозрачность кода, так как интерфейс описан и связывание происходит в рантайм. Недостатки — так как связывание идёт в рантайм то ухудшается производительностью. Насколько этот недостаток критичен — это вопрос конкретной задачи.
Выводы
На данном этапе я для себя уяснил, что: простой тип, структура, Value Class в качестве параметра шаблона — хорошо, так как шаблон улучшает алгоритм, делая его не зависимым от типа используемых данных. Хотя на самом деле наверное хорошо — это только простой тип, так как и структура и Value Class вносит зависимость от интеорфейса в большинстве случаев. Класс с определённой функциональностью — плохо, так как вносит зависимость от интерфейса, явно не определяя этого интерфейса, что приводит к осложненим при отладке.
Я не знаю, что нового собирается M$ привнести в шаблоны, но будем надеятся что это как сказал Влад только улучшит перфоманс и простоту суппорта и отладки, чего не было с старых шаблонах.
Народная мудрось
всем все никому ничего(с).
Будут ли шаблоны и множественное наследование в CLR?
Планирует ли MS в новой версии .NET добавить в C# поддержку шаблонов и множественного наследования классов?
Или, может, в будущем они планируют?
Кто что слышал по этому поводу, поделитесь плиз.
18.02.03 18:22: Перенесено модератором из '.NET' в Философию Программирования — ХД
Re: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, flatch, Вы писали:
F>Планирует ли MS в новой версии .NET добавить в C# поддержку шаблонов и множественного наследования классов? F>Или, может, в будущем они планируют?
Про C# читал на сайте производителя, что в следующей версии будут аналоги шаблонов, а вот насчет множественного наследования сильно сомневаюсь.
Re: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, flatch, Вы писали:
F>Планирует ли MS в новой версии .NET добавить в C# поддержку шаблонов
поддержка шаблонов, ьудет точно.
и множественного наследования классов?
Не этого не будет, т.к. нет смысла, есть множественное наследоваие интерфейсов. Они с самого начала не стали делать множественное наследовние классов, чтобы не было путаницы как VC++.
Re[2]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, darkwolf, Вы писали:
D>Здравствуйте, flatch, Вы писали:
F>>Планирует ли MS в новой версии .NET добавить в C# поддержку шаблонов D>поддержка шаблонов, ьудет точно.
D> и множественного наследования классов? D>Не этого не будет, т.к. нет смысла, есть множественное наследоваие интерфейсов. Они с самого начала не стали делать множественное наследовние классов, чтобы не было путаницы как VC++.
"множественное наследоваие интерфейсов"
Нет никакого множественного наследование интерфейсов. Интерфейсы не содержат кода, от них ничего не может наследоваться. Они служат только для того, чтобы один объект мог быть представлен в разных ролях. Иначе полиморфизм работал бы только на одной ветке иерархии.
Java/C# это языки со строго одиночным наследованием, и никак иначе.
Здравствуйте, _vovin, Вы писали:
V>Нет никакого множественного наследование интерфейсов. Интерфейсы не содержат кода, от них ничего не может наследоваться.
Наследоваться, помимо реализации, может еще и интерфейс. Так что когда пишут так
interface IA : IB, IC
это именно множественное наследование интерфейсов
V> Они служат только для того, чтобы один объект мог быть представлен в разных ролях.
V>>Нет никакого множественного наследование интерфейсов. Интерфейсы не содержат кода, от них ничего не может наследоваться.
AVK>Наследоваться, помимо реализации, может еще и интерфейс. Так что когда пишут так AVK>
AVK>interface IA : IB, IC
AVK>
AVK>это именно множественное наследование интерфейсов
Я бы сказал, что это операция композиции интерфейсов. Наследование несет определенную смысловую нагрузку, связянную с
приобретением данных/кода предка.
Если darkwolf имеет в виду именно композицию интерфейсов, тогда вопрос снимается. Извиняюсь, если не так понял.
AVK> V>> Они служат только для того, чтобы один объект мог быть представлен в разных ролях.
AVK>Они много для чего нужны. Не только для этого.
V>>"множественное наследоваие интерфейсов" V>>Нет никакого множественного наследование интерфейсов.
МС> "... нет никакой ложки ..." (ц) Матрица
V>>Интерфейсы не содержат кода, от них ничего не может наследоваться.
МС> от них может наследоваться... хм... интерфейс...
V>>Java/C# это языки со строго одиночным наследованием, и никак иначе.
МС> имплементации (реализации (для ревнителей чистоты русского языка))
An interface can inherit from zero or more interfaces, which are called the explicit base interfaces of the interface
Если по твоему inherit переводится как композиция то тогда конечно.
V>Наследование несет определенную смысловую нагрузку, связянную с V>приобретением данных/кода предка.
Наследование означает только то что некая сущность приобретает некие свойства от своего родителя и ничего больше. То о чем ты говоришь ты сам придумал. Никогда термин наследование не означал наследование именно кода.
AVK>>Они много для чего нужны. Не только для этого.
V>Да, все это полезные дополнения.
Ну неизвестно что и к чему дополнение. Интерфейс это максимально абстрагированный интерфейс доступа к чему либо. А то что интерфейсы можно использовать в качестве механизма виртуального доступа без изменения иерархии наследования это уже следствие. Интерфейс может накрывать уже существующие методы, реализацией интерфейса может быть статический метод, часть реализации интерфейса может быть недоступна из интерфейса реализующего класса и т.д. Так что не надо сужать понятие интерфейса, оно куда шире. Можешь воспринимать интерфейс как маску, которую надевает класс, чтобы казаться кем то.
Здравствуйте, Lloyd, Вы писали:
L>То, о чем вы говорите, называется наследованием реализации. То о чем говорит AndrewVK -- наследование интерфейса. И то, и другое -- наследование.
Смею заметить что я не говорил что наследование это именно наследование интерфейса. Наследование интерфейса это один из способов наследования. Наследоваться может что угодно, не только интерфейс или код.
И еще, об этом речь недавно велась, но все же. Реализация классом интерфейса ни в коем случае наследованием не является.
Здравствуйте, Lloyd, Вы писали:
L>Повторяю для тех, кто в танке: Реализация классом интерфейса == Наследование интерфейса. L>Это общепринятый термин и не надо пытаться сопоставлять его семантику и этимологию. Этимология не обязана соответствовать семантике.
Абсолютно не соответствует истине.
Реализация классом интерфейса — это "реализация интерфейса" или "выполнение контракта".
Никакого отношения к "наследованию реализации" не имеет, кроме как схожести механизмов реализации "наследования" и "реализации".
Но ни один грамотный человек, например, не поставит знак равенства между "отношением генерализации" и "ассоциацией 1:1", хотя реализуются эти механизмы в физической модели часто одинаково.
Точно также и наследование с реализацией. Реализация интерфейса фактически сводится к таблицам виртуальных методов, но разница есть, и она концептуальная.
Здравствуйте, henson, Вы писали:
H>Здравствуйте, flatch, Вы писали:
F>>Планирует ли MS в новой версии .NET добавить в C# поддержку шаблонов и множественного наследования классов? F>>Или, может, в будущем они планируют?
H>Про C# читал на сайте производителя, что в следующей версии будут аналоги шаблонов, а вот насчет множественного наследования сильно сомневаюсь.
Почитал я про .NET generics. Первое впечатление было: "обманули!" Обещали одно, а подсовывают совсем другое. Много было разговоров о том, что .NET generics будут мощнее тех, что предложены для Java. Сейчас же кажется, что единственное отличие от Java состоит в том, что generics в .NET будут поддерживать простые типы.
Основная идея остается одинаковой: про типы параметризации runtime не знает ничего, поэтому они считаются System.Object'ами.
Например, такое невозможно:
public class Dictionary<KeyType, ValType>
{
public void Add(KeyType key, ValType val)
{
...
switch(key.CompareTo(x)) // CompareTo() doesn't exist for KeyType
{
}
...
}
}
Нужно будет использовать constraints:
public class Dictionary<KeyType, ValType> where KeyType : IComparable
Понятия специализации для generics нет, typedef нет, generics для отдельных методов тоже нет.
Общее впечатление такое, что generics будут использоваться только для чего-нибудь простого вроде реализации типизированных коллекций.
Re[3]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, alexkro, Вы писали:
A>Например, такое невозможно:...
Честно говоря не ясно почему.
A>Понятия специализации для generics нет, typedef нет, generics для отдельных методов тоже нет.
Ну и на фиг все жто? Разве что для методов можно было бы оставить.
A>Общее впечатление такое, что generics будут использоваться только для чего-нибудь простого вроде реализации типизированных коллекций.
Дык вся соль в том, что в С++ шаблоны давно превратились из средства создания полиморфных алгоритмов в средства исправления проблем языка. Ух лучше пусть сам язык будет более стройным. К тому же у них есть еще одна очень важная задача. Им нужно сохранить в Шарпе простоту. Если насувать всех приколов из С++ в Шарп, то чем тогда Шарп будет лучше С++? С++ ведь никто не отменял! Хочешь выпендриваться создавай проект на МС++. Он уже в VS.NET 2003 очень прилично стал выглядеть.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, alexkro, Вы писали:
A>Почитал я про .NET generics. Первое впечатление было: "обманули!" Обещали одно, а подсовывают совсем другое. Много было разговоров о том, что .NET generics будут мощнее тех, что предложены для Java. Сейчас же кажется, что единственное отличие от Java состоит в том, что generics в .NET будут поддерживать простые типы.
A>Основная идея остается одинаковой: про типы параметризации runtime не знает ничего, поэтому они считаются System.Object'ами.
Плохо читал. Главное отличие дженериков в джаве от дженериков в дотнете именно в том что последние реально существуют в рантайме. Поищи в поиске, тут как то эта тема подробно обсасывалась, с примерами кода.
Здравствуйте, Lloyd, Вы писали:
L>Повторяю для тех, кто в танке: Реализация классом интерфейса == Наследование интерфейса.
Ну что — опять по новой? Я даже Владу доказал что это не так. В общем берем документацию по шарпу и внимательно читаем, осозновая разницу между словами inherits и implements. А на закуску рекомендую подумать — что именно наследует класс у реализуемого им интерфейса.
L>Это общепринятый термин
Гонишь ты все. Это ошибочное использование термина, вызваное тем что в С++ интерфейс реализуется на основе абстрактных классов. интерфейс дотнета != интерфейс СОМ и термин наследование при реализации в случае дотнета не применим.
L> и не надо пытаться сопоставлять его семантику и этимологию. Этимология не обязана соответствовать семантике.
Здравствуйте, Lloyd, Вы писали:
L>Ваша ошибка была в том, что вы не восприняли эти термины именно как термины, а пытались из их "звучания" выудить какой-то дополнительный смысл.
Есть еще смысл слова наследование. Если называть танк самолетом ни к чему хорошему это не приведет.
L> Не всегода стоит делать это. Иногда стоит и почитать книжки, в которых эти термины объяснялись.
Иногда стоит почитать документацию по языку. Есть термин — реализация интерфейса. Вот его и следует употреблять.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alexkro, Вы писали:
A>>Например, такое невозможно:...
VD>Честно говоря не ясно почему.
VladD2, почитай статью, на которую я дал ссылку. Необходимо делать либо явный cast, либо использовать constraints.
A>>Понятия специализации для generics нет, typedef нет, generics для отдельных методов тоже нет.
VD>Ну и на фиг все жто? Разве что для методов можно было бы оставить.
A>>Общее впечатление такое, что generics будут использоваться только для чего-нибудь простого вроде реализации типизированных коллекций.
VD>Дык вся соль в том, что в С++ шаблоны давно превратились из средства создания полиморфных алгоритмов в средства исправления проблем языка. Ух лучше пусть сам язык будет более стройным. К тому же у них есть еще одна очень важная задача. Им нужно сохранить в Шарпе простоту. Если насувать всех приколов из С++ в Шарп, то чем тогда Шарп будет лучше С++? С++ ведь никто не отменял! Хочешь выпендриваться создавай проект на МС++. Он уже в VS.NET 2003 очень прилично стал выглядеть.
C++ templates не очень приятно использовать вместе с managed объектами. Многое приходится делать через gcroot<>, который очень сильно замедляет доступ к объекту.
Я надеялся, что с появлением generics С++ сможет компилировать некоторые темплэйты в managed code. Не тут-то было .
Re[5]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, alexkro, Вы писали:
A>VladD2, почитай статью, на которую я дал ссылку. Необходимо делать либо явный cast, либо использовать constraints.
Ты все таки воспользуйся поиском. Мы эту статью уже читали и даже обсуждали здесь. Констрейнты возможны в принципе только если есть поддержка дженериков в рантайме. Про то какой будет у шаблонов рефлекшен в статье ни слова. А то о чем ты говоришь будет реализовываться через рефлекшен, а не через конситрукции языка.
A>Я надеялся, что с появлением generics С++ сможет компилировать некоторые темплэйты в managed code. Не тут-то было .
Нет, дженериксы и шаблоны это далеко не одно и то же. В статье, о которой ты упоминаешь, даже глава специальная на эту тему есть.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну что — опять по новой? Я даже Владу доказал что это не так.
Не путай слова "даказал" и доказывал. Я своего мнения не изменил. Слова унаследовать интерфейс совершенно законны.
AVK>В общем берем документацию по шарпу и внимательно читаем, осозновая разницу между словами inherits и implements.
В Шарпе и взяли такой синтаксис потому что имплемент — это и есть наследование интерфейса. В общем бери книжки по ОО и чита.
PS
Расслябься и воспринимай мир таким какой он есть. Люди привыкли говорить "наледование интерфейса" и они говорить так будут. Даже если тебе это не нарвится.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В Шарпе и взяли такой синтаксис потому что имплемент — это и есть наследование интерфейса. В общем бери книжки по ОО и чита.
Я их читал. В спецификации языка я такого не заметил. Если ты где читал именно про наследование интерфейса не применительно к С++ то кинь ссылку или цитату.
F>>Планирует ли MS в новой версии .NET добавить в C# поддержку шаблонов и множественного наследования классов? F>>Или, может, в будущем они планируют? F>>Кто что слышал по этому поводу, поделитесь плиз.
Tom>Вопрос как мне кажется не в том будут ли шаблоны, а в том нужны ли они. На мой взгляд шаблоны — ошибочная ветка развития ООП и в .NET не нужны. Абсолютно любую задачу, рещаемую при помощи шаблонов можно решить более красиво и более просто.
На www.csharp.net лежит в числе первых ссылок описание новых конструкций в следующей версии C#. В частности, будут и шаблоны. Аргументация очень убедительная.
Сейчас нет готового метода сделать хорошую collection для типов ValueType. Всё время лезет boxing/unboxing. Это обсуждается как раз в другой ветке.
В будующей реализации шаблонов такое будет поддерживаться, причём автоматически, без раздумий со стороны разработчика.
VD>>В Шарпе и взяли такой синтаксис потому что имплемент — это и есть наследование интерфейса. В общем бери книжки по ОО и чита.
AVK>Я их читал. В спецификации языка я такого не заметил. Если ты где читал именно про наследование интерфейса не применительно к С++ то кинь ссылку или цитату.
Как весь трындец!
Вопрос стоял о том, будет ли множественное наследование. Нет, пока не будет, и вообще это не ложится в идеологию .NET. Хотя есть языки, реализующие такие навороты, например, Eiffel. Как они это делают — не знаю, но уверен, что несовместимо с CLS, то есть их множественное наследование не будет таковым с точки зрения C#, VB, или Delphi for .NET.
А спор о том, наследуются интерфейсы или реализуются — пустая трата времени. Вон, люди советуются, как правильно писать int или System.Int32 — примерно та же бодяга.
... << RSDN@Home 1.0 beta 6a >>
Re[3]: Будут ли шаблоны и множественное наследование в CLR?
M>На www.csharp.net лежит в числе первых ссылок описание новых конструкций в следующей версии C#. В частности, будут и шаблоны. Аргументация очень убедительная.
M>Сейчас нет готового метода сделать хорошую collection для типов ValueType. Всё время лезет boxing/unboxing. Это обсуждается как раз в другой ветке.
Ну это ты соврал конечно. Можно и без проблемм.
M>В будующей реализации шаблонов такое будет поддерживаться, причём автоматически, без раздумий со стороны разработчика.
ну ну. а может тогда попросить M$ написать VisualStudio 3000 в котором надо будет просто словами сказать: "Хочу новую оп систему, что бы не глючила и была совместимая со ВСЕМИ В МИРЕ" и пойти кофе пить.
Народная мудрось
всем все никому ничего(с).
Re[4]: Будут ли шаблоны и множественное наследование в CLR?
M>>Сейчас нет готового метода сделать хорошую collection для типов ValueType. Всё время лезет boxing/unboxing. Это обсуждается как раз в другой ветке. Tom>Ну это ты соврал конечно. Можно и без проблемм.
По моему мнению, можно, но затруднительно. Если ты знаешь лёгкий путь, подскажи, пожалуйста.
M>>В будующей реализации шаблонов такое будет поддерживаться, причём автоматически, без раздумий со стороны разработчика. Tom>ну ну. а может тогда попросить M$ написать VisualStudio 3000 в котором надо будет просто словами сказать: "Хочу новую оп систему, что бы не глючила и была совместимая со ВСЕМИ В МИРЕ" и пойти кофе пить.
Ты знаешь, я не против!
... << RSDN@Home 1.0 beta 6a >>
Re[5]: Будут ли шаблоны и множественное наследование в CLR?
M>По моему мнению, можно, но затруднительно. Если ты знаешь лёгкий путь, подскажи, пожалуйста.
Да в общем вариантов куча. Можно на основе массивов. Только опять же зачем это делать. Думаю сравнив производительность большого выигрыша не получится.
Здравствуйте, mihailik, Вы писали:
M>Нет, пока не будет, и вообще это не ложится в идеологию .NET. Хотя есть языки, реализующие такие навороты, например, Eiffel. Как они это делают — не знаю, но уверен, что несовместимо с CLS,
Совместимо Они при компиляции генерят спец. классы — гибриды множественно отнаследованных.
Множественную реализацию можно и на шарпе сделать — поищи в поиске, я сюда пример такого кидал.
AVK>Просто имхо шаблоны не очень гибкая вещь, варианты параметров весьма ограничены. Я бы предпочел встроенную в код полномасштабную поддержку кодогенерации а не затычки ввиде шаблонов.
Здравствуйте, AndrewVK, Вы писали:
AVK>Я их читал. В спецификации языка я такого не заметил. Если ты где читал именно про наследование интерфейса не применительно к С++ то кинь ссылку или цитату.
Это можно прочесть вообще в любой книге посвященной ОО-дизайну, т.е. не тяготеющих к конкретному языку.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, Tom, Вы писали:
Tom>Вопрос как мне кажется не в том будут ли шаблоны, а в том нужны ли они. На мой взгляд шаблоны — ошибочная ветка развития ООП и в .NET не нужны. Абсолютно любую задачу, рещаемую при помощи шаблонов можно решить более красиво и более просто.
Ты вкурсе насколько дорого обходятся боксинг и приведение типов? А сколько стоят виртуальные вызовы?
Да и вообще... попробуй рассказать про эту "красоту".
Вот создание типизированной коллекции в одну строку да еще и в разы более быструю — это аргумент:
Collection<MyType> _MyCollection;
Tom>PS: Помидорами не кидать. Основываюсь на своём опыте разработки и применении шаблонов.
Странный у тебя опыт.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, AndrewVK, Вы писали:
AVK>В общем то правильно, вот только перфоманс, поганка эдакая, всю малину портит. А так конечно без них проще.
Тем кто ими пользоваться не нуавчился. Шаблоны дают не только скорость, но и типобезопастность. Без них все потуги к большей типозащищенности всего лишь полумеры.
AVK>Просто имхо шаблоны не очень гибкая вещь,
Гы-гу. С++ только за их счет и вылез.
AVK>варианты параметров весьма ограничены. Я бы предпочел встроенную в код полномасштабную поддержку кодогенерации а не затычки ввиде шаблонов.
Ерунду ты говоришь. Все же прежде чем судить о чем-то нужно это что-то как следует попробывать. Покажи хотя-бы один класс который ты написал на шблонах.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, mihailik, Вы писали:
M>Сейчас нет готового метода сделать хорошую collection для типов ValueType. Всё время лезет boxing/unboxing. Это обсуждается как раз в другой ветке.
Ладно тебе. Что уж там для вэлью-типо. Даже обычную типизированную коллекцию делать замучаешся. Люди клепают кодогенерацию и т.п. А ведь в дотнет обещают сделать не просто шаблоны, а "умные" шаблоны которые не будут приводить к разуванию кода.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, Tom, Вы писали:
M>>Сейчас нет готового метода сделать хорошую collection для типов ValueType. Всё время лезет boxing/unboxing. Это обсуждается как раз в другой ветке. Tom>Ну это ты соврал конечно. Можно и без проблемм.
Пример в студию! И оцени объем кода.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, Tom, Вы писали:
Tom>Да в общем вариантов куча. Можно на основе массивов. Только опять же зачем это делать. Думаю сравнив производительность большого выигрыша не получится.
А ты не думай, а сравни. Если возьмешь ArrayList, но на вылью-типах получишь такой провал производительности, что самому противно статент. Мы тут с AVK, как то на эту тему беседовали. Я ему приводил примерчик. Назница на парядки.
Если же сделаешь на типизированных массивах, то для каждого типа элемента придется писать свой динмический массив и свой варинт коллекции. Собственно от этого и избавляют шаблоны.
Короче, если что-то кажется непонятныи и пугающим, не нужно сразу на него ставить "ярлык". Лучше сначала разобраться и попробывать.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, VladD2, Вы писали:
VD>Ерунду ты говоришь. Все же прежде чем судить о чем-то нужно это что-то как следует попробывать.
Все уже давно попробованно. Я предлагаю пойти дальше — шаблоны позволяют параметризовать типы. А почему бы в качестве параметров не использовать секции кода, названия классов и свойств и т.д. ? В этом случае область применения шаблонов значительно расширилась бы. Например можно было бы реализовать весь стандартный набор паттернов ввиде таких шаблонов.
VD> Покажи хотя-бы один класс который ты написал на шблонах.
В смысле на плюсовых? Вряд ли найду, давно это было.
Tom>>PS: Помидорами не кидать. Основываюсь на своём опыте разработки и применении шаблонов.
VD>Странный у тебя опыт.
Опыт суппорта продуктов в десятки мегабайт кода. В которых НЕВОЗМОЖНО в принципе разобраться что к чему из за обилия шаблонов и стиля их написания. К примеру попробуй полностью разобраться как реализован у M$ STL. А если на них ещё навёрнуто 5-6 слоёв то как ??? Возникает ОЧЕНЬ много вопросов. Если бы использовались интерфейсы, то решения были бы на много прозрачнее. Хотя это вопрос вкусов, о которых как известно.... Но мо странный опыт суппорта говорит, что это очень плохое решение.
Народная мудрось
всем все никому ничего(с).
Re[7]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Tom, Вы писали:
M>>>Сейчас нет готового метода сделать хорошую collection для типов ValueType. Всё время лезет boxing/unboxing. Это обсуждается как раз в другой ветке. Tom>>Ну это ты соврал конечно. Можно и без проблемм.
VD>Пример в студию! И оцени объем кода.
VD>
Достали в общем. Пошол писать. Буду недели через 2. Спорим на пиво, что не уступлю более чесм 30%.
Народная мудрось
всем все никому ничего(с).
Re[6]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, Tom, Вы писали:
Tom>Я и не ставлю. Просто выигрывая в одном проигрываешь в другом. Выигрывая во времени написания проекта проигрываешь во времени отладки и суппорта.
Генерики способны только ускорить разработку (так как не нужно писать лишний код). И упростить отладку (так как типобезопастность повышается).
Пойми, это просто возможность записать алгоритм абстрагируясть от конкретных типов данных. Ведь без них ты или вынужден писть отдельные реализации для каждого типа. Или делать все полиморфным. Ну спервым понятно. И отладка, и поддержка, и поре кода... Ну а полиморфный подход дает длве проблемы. Неоптимальную производительность (особенно с вэлью-типами, из-за боксинка). И отсуствие типобезопастности. Минусов нет. Вы их придумываете.
А в других местах их применять не нужно. Тогда и проблем не будет.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, Tom, Вы писали:
Tom>Опыт суппорта продуктов в десятки мегабайт кода. В которых НЕВОЗМОЖНО в принципе разобраться что к чему из за обилия шаблонов и стиля их написания.
Может дело в стиле их написания? Вот возьми к примеру ATL/WTL. Шаблонов море. Но разобраться в них раз плюнуть. Народ справляется даже без документации.
Tom>К примеру попробуй полностью разобраться как реализован у M$ STL.
Ну я в общем разбирался. Проблем особых нет. Только два замечания:
1. STL довольно кривая по дизайну библиотека.
2. МС к ней отношение имее очень отдаленная. Это скорее HP.
Tom>А если на них ещё навёрнуто 5-6 слоёв то как ???
Слышал про такое понятие — абстракция? Надеюсь, да. Так вот если абстракция хорошо продумана и воплощена шаблоном, то пользоваться ею очень прото и удобно. В то же время ту же абстракцию можно воплотить методом полиморфизма и получить очень плохой результат (то о чем ты говоришь). В общем, дело не в методе реализации абстракции, а в грамотности ее проработки.
Шарп пробще С++, не из-за того что в нем нет шаблонов, а из-за того, что его разработчики попытались по-максимуму облегчить все конструкции языка. К примеру, указатели и адресная арифметика переведена в разряд хакерства и моветона. Причем обеспечено все необходимое, чтобы программист не чуствовал себя ущербным без адресной арифметики. Тоже самое, надеюсь, будет и с шаблонами.
Tom>Возникает ОЧЕНЬ много вопросов. Если бы использовались интерфейсы, то решения были бы на много прозрачнее.
А что? Шаблоны отменяют интерфейсы? Ты путаешь дотнет с комом. Это в коме нельзя было использовать шаблоны. В Шарпе это как раз будет возможно. К примеру вместо дурацкого IList, где все методы описаны через object. Будет IList<T>. Где T — это тип элемента. Причем IList<T> ничем ни в чем остальном (кроме типизированности) не будет отличаться от своего пропращура. Даже будет доспупен решлекшон.
Tom>Хотя это вопрос вкусов, о которых как известно.... Но мо странный опыт суппорта говорит, что это очень плохое решение.
Ну приведи пример который покажет, что использование шаблонов дает менее читаемый код или ухудшает отладку.
PS
Учти в шарпе не будет многих проблем которые были в С++. И синтаксис шаблонов будет тоже проще.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, AndrewVK, Вы писали:
AVK>Все уже давно попробованно. Я предлагаю пойти дальше — шаблоны позволяют параметризовать типы. А почему бы в качестве параметров не использовать секции кода, названия классов и свойств и т.д.?
Все же по твоим словм сразу видно, что опыт работы на плюсах у тебя очень маленький. То что ты предлагаешь давно было еще в старом добром С (без плюсов). Назывлось макросами. Так вот опыт показал, что это приводит к жутчайшему беспределу. Когда появились шаблоны, многие заговорили о том, что еще немного и про ад макросов можно будет забыть.
Честно говоря макросы в умелых руках вещь мощьная. Н к сожелению проблем у них хватает. Вероятно можно придумать концепцию типизированных макросов, но это уже скорее всего будет развитием шаблонов.
AVK>В этом случае область применения шаблонов значительно расширилась бы.
Во-во. На маросах можно намного больше чем на шаблонах. Можно даже шаблоны эмулировать. Только радости от этого никакой.
AVK>Например можно было бы реализовать весь стандартный набор паттернов ввиде таких шаблонов.
Их и в виде обычных классав (ну максимум с шаблонами) можно реализовать.
AVK>В смысле на плюсовых? Вряд ли найду, давно это было.
Оно и чувствуется. Я просто уверен, что после того как в Шарпе появятся шаблоны ты будеш одним из первых их поклонников. Помяни мое слово. Мы создавая С++-код в конце концов 80% стали делать на шаблонах. Так как это и шустрее и проще.
Ну а если Шаблоны решат проблему подключения реализации к интерфейсам, то им вообще цены не будет.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, VladD2, Вы писали:
VD>Все же по твоим словм сразу видно, что опыт работы на плюсах у тебя очень маленький.
Давай не будем здесь обсуждать мой опыт работы на плюсах? ОК?
VD> То что ты предлагаешь давно было еще в старом добром С (без плюсов). Назывлось макросами.
Ничего похожего. Рекомендую поглядеть на тугезу и посмотреть как там реализованы паттерны. Вот хотелось бы поддержку подобного со стороны языка чтобы не приходилось городить 2-way tools.
VD>Их и в виде обычных классав (ну максимум с шаблонами) можно реализовать.
Эффективно, да еще с типизацией, нельзя. Потому как параметрами паттернов могут быть не только типы.
VD>Оно и чувствуется. Я просто уверен, что после того как в Шарпе появятся шаблоны ты будеш одним из первых их поклонников. Помяни мое слово. Мы создавая С++-код в конце концов 80% стали делать на шаблонах. Так как это и шустрее и проще.
Я где то писал что мне шаблоны не нравятся и так не шустрее и не проще?
Здравствуйте, AndrewVK, Вы писали:
VD>>Все же по твоим словм сразу видно, что опыт работы на плюсах у тебя очень маленький. AVK>Давай не будем здесь обсуждать мой опыт работы на плюсах? ОК?
Правильно. Будем обсуждать вкус устриц с теми кто их не пробывал.
VD>> То что ты предлагаешь давно было еще в старом добром С (без плюсов). Назывлось макросами.
AVK>Ничего похожего. Рекомендую поглядеть на тугезу и посмотреть как там реализованы паттерны. Вот хотелось бы поддержку подобного со стороны языка чтобы не приходилось городить 2-way tools.
Ты описал макросы (практически точное определение дал).
VD>>Их и в виде обычных классав (ну максимум с шаблонами) можно реализовать. AVK>Эффективно, да еще с типизацией, нельзя. Потому как параметрами паттернов могут быть не только типы.
Я еще раз повторяю... ты просто никогда не использовал шаблонов и не понимаешь всей их гибкости. Через параметры можно передавать как просто типы данных, так и логику. В конце коныов любой класс может содержать логику.
VD>>Оно и чувствуется. Я просто уверен, что после того как в Шарпе появятся шаблоны ты будеш одним из первых их поклонников. Помяни мое слово. Мы создавая С++-код в конце концов 80% стали делать на шаблонах. Так как это и шустрее и проще.
AVK>Я где то писал что мне шаблоны не нравятся и так не шустрее и не проще?
А то? Вот (двумя ветками выше):
Tom>>Вопрос как мне кажется не в том будут ли шаблоны, а в том нужны ли они. На мой взгляд шаблоны — ошибочная ветка развития ООП и в .NET не нужны. Абсолютно любую задачу, рещаемую при помощи шаблонов можно решить более красиво и более просто.
AVK>В общем то правильно, вот только перфоманс, поганка эдакая, всю малину портит. А так конечно без них проще. AVK>Просто имхо шаблоны не очень гибкая вещь, варианты параметров весьма ограничены. Я бы предпочел встроенную в код полномасштабную поддержку кодогенерации а не затычки ввиде шаблонов.
Твои слова? Из них однозначный вывод, что если кроме скорости кода шалоны ничего не дают.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, VladD2, Вы писали:
VD>Я еще раз повторяю... ты просто никогда не использовал шаблонов и не понимаешь всей их гибкости. Через параметры можно передавать как просто типы данных, так и логику. В конце коныов любой класс может содержать логику.
А что средствами ООП не получится, даже паттерн специальный есть, только вот забыл как он называеься.
... << RSDN@Home 1.0 beta 3 >>
Re[8]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, VladD2, Вы писали:
AVK>>Ничего похожего. Рекомендую поглядеть на тугезу и посмотреть как там реализованы паттерны. Вот хотелось бы поддержку подобного со стороны языка чтобы не приходилось городить 2-way tools.
VD>Ты описал макросы (практически точное определение дал).
Нет, макросы это слишком примитивно.
VD>Я еще раз повторяю... ты просто никогда не использовал шаблонов и не понимаешь всей их гибкости. Через параметры можно передавать как просто типы данных, так и логику. В конце коныов любой класс может содержать логику.
Если тащить эту логику в отдельном классе то весь кайф шаблонов пропадает.
AVK>>Я где то писал что мне шаблоны не нравятся и так не шустрее и не проще?
VD>А то? Вот (двумя ветками выше):
Вот и приведи цитату. Я всего лишь сказал что шаблоны можно было бы сделать погибче. Но это не значит что шаблоны в теперешнем виде не нужны. Ты как всегда начинаешь читать между строк.
AVK>>Просто имхо шаблоны не очень гибкая вещь, варианты параметров весьма ограничены. Я бы предпочел встроенную в код полномасштабную поддержку кодогенерации а не затычки ввиде шаблонов.
VD>Твои слова? Из них однозначный вывод, что если кроме скорости кода шалоны ничего не дают.
По сравнению с полиморфизмом и рефлекшеном? Да, практически ничего. Все остальные их фичи без проблем реализуются.
Здравствуйте, AndrewVK, Вы писали:
AVK>Нет, макросы это слишком примитивно.
Эта та самая кодогенерация при компиляции о которой ты говорил. Причем на макросах действительно можно очень многое. При грамотном использовании они позволяют превратить ужасные конструкции в простые и понятные абстракции (типа мапов из АТЛ). Но вот в руках новичков — это страшно.
AVK>Если тащить эту логику в отдельном классе то весь кайф шаблонов пропадает.
Далее можно создать несколько реализация Comparer-а эффктивно сравнивающих элементы разных типов. Более того можно создать Comparer который осуществляет разные алгоритмы сравнения и использовать нуждый в определенных местах.
Конечно можно можн все тоже самое сделать на полиморфизме (интерфейсах или делегатах принемающих в качестве параметра object-ы), но это приведет к сильному подению производительности и трудно уловимым рантайм ошибкам.
AVK>Вот и приведи цитату. Я всего лишь сказал что шаблоны можно было бы сделать погибче. Но это не значит что шаблоны в теперешнем виде не нужны. Ты как всегда начинаешь читать между строк.
Тебе нельзя привести цитату если ты уже понял, что был не првл.
AVK>По сравнению с полиморфизмом и рефлекшеном? Да, практически ничего. Все остальные их фичи без проблем реализуются.
Трепачь находка для шпиенов. Если все легко реализовалось, то МС с шаблонами бы и не дергалось. В общем спорить с тобей безсмысленно. Вот появятся шаблоны посмотрим как ты без них будет обходиться. Уверяю теб что ты первый будешь их использовать и проблема производительности будет далеко не на первом месте.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, kreek, Вы писали:
K>А что средствами ООП не получится, даже паттерн специальный есть, только вот забыл как он называеься.
Можно то оно можно. Но ты зароешься в приведениях типов и рантйме. С шаблонами все проще.
Я тут уже несколько раз повторил, что шаблоны позволяют писать быстрый типобезопасный код и избегать дублирования. Писать можно и без них. Но с ними удобнее.
Одна типобезопастность уже неоспоримое достоинство. В С++ с помощью шаблонов и переопределения операторов народ творит чудеса. Надеюсь в Шарпе будет также.
PS
Заметьте. Среди людей наезжающих на шаблоны (ну или пытающихся свести их достоинства только к увеличению производительности) все не имели большого опыта работы с шаблонами. А все кто успешно использовал шаблоны в С++ ждут их пояления в Шарпе. Это явно не спроста.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Будут ли шаблоны и множественное наследование в CLR?
Маленькое введение. Прошу в дальнейшем не высказываться с позиции безапиляционно правого. Это конечно хорошо, что ты опытен во многих вещах, но мы ведём дискуссию, а не лекцию
VD>Это без разницы будет там слово class или нет. А то что шаблон будет строиться на базе интерфейса типа данных T — это большое приимущетсво, так как все проверки можно будет сделать дизайнтайме. И тебе просто не дадут скомпилировать Foo<Some> если Some не поддерживает нужной для Foo функциональности.
И кто сказал, что это хорошо. Это вообще тема для отдельной бисседы и изучения. Вон в коме всё в рантайм и работает прекрасно. Никаких проблемм с контролем типов. И проблемм меньше, так как модули изолированны и работа идёт только при помощи интерфейсов.
VD>Нет не сможешь. Нано или поздно ты скатишся на поля/параметры типа object и как следствие потерю производительности и проблемы с контролем типов (который придется выполнять в рантайме и вручную).
Пойми одну простую вещь. Я разделяю для себя 2 случая. 1 — когда параметром шаблона является простой тип. 2 — когда класс или интерфейс (не шаблонный). Так вот в 1 случае шаблоны хорошо (док. см. в предыдущем посте), а во втором — плохо. По поводу производительности — это то же отдельный разговор.
Tom>>Итак какие мы получаем выгоды. Прозрачность кода, так как интерфейс описан и связывание происходит в рантайм. Недостатки — так как связывание идёт в рантайм то ухудшается производительностью. Насколько этот недостаток критичен — это вопрос конкретной задачи.
VD>Ну выводы сделанные на неверных предпосылках...
Ну ну. Зайди ка в форус по C++ и посмотри какие у народа проблеммы и с чем... Кстате посмотрим на этот форум после введения этих шаблонов.
VD>Так что лучше не надо философии вот тебе обратно обычный IList и его индексатор: VD>
VD>Попробуй использовать свой интерфейс.
Так я же говорил уже, что если параметр — простой тип то хорошо.
Tom>>Выводы Tom>>На данном этапе я для себя уяснил, что: простой тип, структура, Value Class в качестве параметра шаблона — хорошо, так как шаблон улучшает алгоритм, делая его не зависимым от типа используемых данных. Хотя на самом деле наверное хорошо — это только простой тип, так как и структура и Value Class вносит зависимость от интеорфейса в большинстве случаев.
VD>Глупость. Зависимость от интерфейса будет всегда. Действи типа "=", "==", "+" и т.п. — это тоже интерфейс. Весь кайф шаблонов, в том что ты можешь пользоваться им наиболее эффективно и не прибегать к полиморфизму. Более того шаблоны дают некий упрощенных статический полиморфизм, который намного более безопасен и эффективен.
Про "=", "==", "+" — полностью с тобой согласен и очень жалею, что перегрузка операторов есть в .NET. В Java её нет и никто об этом не парится, кроме любителей C++. По поводу шаблонов — никакого понимаешь упращения. Единственный плюс — независимость алгоритма от типа данных.
Tom>>Класс с определённой функциональностью — плохо, так как вносит зависимость от интерфейса, явно не определяя этого интерфейса, что приводит к осложненим при отладке.
VD>Полнейшая ерунда. VD>Никаких осложнений при отладке нет. Это проверено тем же С++. На заре С++ были проблемы с отладчиками, но сегодня таких проблем нет и шалблоны прекрасно отлаживаются.
Проверено на C++ что проблемм куча. Как ты думаешь сколько примерно займёт на экране 800*600 сообщение об ошибке выданное gcc на какую нибудь ошибку в классе map<string, string>. Пол экрана идёт только перечисление класса.
ЗЫ: В принципе если шаблоны упростят и так как нет множественного наследования, то не всё так плохо
Здравствуйте, AndrewVK, Вы писали:
AVK>... Интерфейс это максимально абстрагированный интерфейс доступа к чему либо. ... Непробовал толковые словари писать? У тя определенно талант.
Твое определение интерфейса просто супер — "интерфейс — это интерфейс"!
Емко... Внушает...
AVK>An interface can inherit from zero or more interfaces, which are called the explicit base interfaces of the interface
AVK>
AVK>Если по твоему inherit переводится как композиция то тогда конечно.
V>>Наследование несет определенную смысловую нагрузку, связянную с V>>приобретением данных/кода предка.
AVK>Наследование означает только то что некая сущность приобретает некие свойства от своего родителя и ничего больше. То о чем ты говоришь ты сам придумал. Никогда термин наследование не означал наследование именно кода.
Я на практике никогда не пользовался наследованием интерфейсом, что даже забыл, что такое понятие существует.
То, что наследование может быть использовано не только для кода, не спорю.
AVK>>>Они много для чего нужны. Не только для этого.
V>>Да, все это полезные дополнения.
AVK>Ну неизвестно что и к чему дополнение. Интерфейс это максимально абстрагированный интерфейс доступа к чему либо. А то что интерфейсы можно использовать в качестве механизма виртуального доступа без изменения иерархии наследования это уже следствие. Интерфейс может накрывать уже существующие методы, реализацией интерфейса может быть статический метод, часть реализации интерфейса может быть недоступна из интерфейса реализующего класса и т.д. Так что не надо сужать понятие интерфейса, оно куда шире. Можешь воспринимать интерфейс как маску, которую надевает класс, чтобы казаться кем то.
Интерфейс это всего лишь навсего некоторый зафиксированный протокол сообщений. Если мы, скажем, ограничим этот протокол одним методом, то, в принципе, с технической точки зрения мы ничего не потеряем. А это уже очень напоминает, хм... делегата. И далее простой подстановкой интерфейс->делегат мы можем сохранить все возможности.
Как ты выразился интерфейс это маска, надеваемая на объект. Все остальное — его удачное применения.
Первоначальное назначение интерфейса — поддержка полиморфизма вне дерева наследования. Правда у COM нет никакого дерева, там все грубо говоря Object, но назначение такое же — представление одного объекта в разных ролях.
Здравствуйте, work69, Вы писали:
AVK>>... Интерфейс это максимально абстрагированный интерфейс доступа к чему либо. ... W> Непробовал толковые словари писать? У тя определенно талант. W>Твое определение интерфейса просто супер — "интерфейс — это интерфейс"! W>Емко... Внушает... W>
К сожалению здесь есть путаница в терминах. Интерфейсом называется собственно элемент языка и рантайма и им же называется набор точек доступа к классу. Нормальных эквивалентов я подобрать не могу, а поскольку здесь я все таки не словарь пишу, то написал так намеренно, надеюсь кому надо меня поняли.
Здравствуйте, VladD2, Вы писали:
AVK>>Нет, макросы это слишком примитивно.
VD>Эта та самая кодогенерация при компиляции о которой ты говорил.
Нет. Макросы не имеют ровно никакой связи с семантическими структурами программы, а тем паче с рантаймом. В этом их фатальный недостаток .
VD>Конечно можно можн все тоже самое сделать на полиморфизме (интерфейсах или делегатах принемающих в качестве параметра object-ы), но это приведет к сильному подению производительности и трудно уловимым рантайм ошибкам.
Влад, это мне напоминает разговор немого с глухим. Не надо мне доказывать что шаблоны это хорошо. Я с этим не спорю. Я говорю о другом — шаблоны можно зделать гибче, дав им возможность манипулирования не только типами, а любой сущностью CodeDOM. Именно CodeDOM
, а не исходниками программы, как в случае макросов.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, work69, Вы писали:
AVK>>>... Интерфейс это максимально абстрагированный интерфейс доступа к чему либо. ... W>> Непробовал толковые словари писать? У тя определенно талант. W>>Твое определение интерфейса просто супер — "интерфейс — это интерфейс"! W>>Емко... Внушает... W>>
AVK>К сожалению здесь есть путаница в терминах. Интерфейсом называется собственно элемент языка и рантайма и им же называется набор точек доступа к классу. Нормальных эквивалентов я подобрать не могу, а поскольку здесь я все таки не словарь пишу, то написал так намеренно, надеюсь кому надо меня поняли.
Данная фраза — свидетельство некоторой закомплексованности мышления.
Это тоже самое что сказать что в словосочетаниях "кресло-качалка" и "кресло-кровать" — слово "кресло"
имеет принципиально другой смысл. Не надо пытаться провести раздел — мир един и понятие
интерфейса едино и не меняется в зависмости от словосочетания в котором оно употребляется
(Юзер интерфейс, аппаратный интерфейс и т.д и т.п.). Говоря в терминах ООД словосочетания вроде "Юзер интерфейс" и т.п являются терминальными классами одного базового абстрактного класса — "интерфейс". (Эко завернул-то )
Понятие интерфейса всегда сводится к одному и тому же — это уровень абстракции представляющий собой систему соглашений и средств для взаимодействия каких либо сущностей. Суть вседа одна.
Зри в корень.(С)Козьма Прутков
Найди всему начало и ты многое поймешь.(С)Козьма Прутков
Не судите да не судимы будете.
K>Это тоже самое что сказать что в словосочетаниях "кресло-качалка" и "кресло-кровать" — слово "кресло" K>имеет принципиально другой смысл. Не надо пытаться провести раздел — мир един и понятие K>интерфейса едино и не меняется в зависмости от словосочетания в котором оно употребляется
Надо читать весь топик. Существует кроме того некая сущность интерфейс, представленная в MSIL.
Так что не стоит меня учить.
Здравствуйте, Tom, Вы писали:
VD>>Полнейшая ерунда. VD>>Никаких осложнений при отладке нет. Это проверено тем же С++. На заре С++ были проблемы с отладчиками, но сегодня таких проблем нет и шалблоны прекрасно отлаживаются. Tom>Проверено на C++ что проблемм куча. Как ты думаешь сколько примерно займёт на экране 800*600 сообщение об ошибке выданное gcc на какую нибудь ошибку в классе map<string, string>. Пол экрана идёт только перечисление класса.
Незнаю как у вас в GCC а у нас в VS7 все просто
std::map<DWORD, T_RefStrong<C_Device> >
e:\work\!!!!!!!!!!!!!\OPCServer\DeviceHost\C_Device.cpp(23): error C2679: binary '=' : no operator found which takes a right-hand operand of type 'T_RefStrong<P_Type>' (or there is no acceptable conversion)
with
[
P_Type=C_Device
]
e:\work\!!!!!!!!!!!!!\OPCServer\DeviceHost\C_Device.cpp(35): error C2440: 'initializing' : cannot convert from 'T_RefStrong<P_Type>' to 'C_DeviceItem *'
with
[
P_Type=C_Device
]
e:\work\!!!!!!!!!!!!!\OPCServer\DeviceHost\C_Device.cpp(41): error C2679: binary '=' : no operator found which takes a right-hand operand of type 'T_RefStrong<P_Type>' (or there is no acceptable conversion)
with
[
P_Type=C_DeviceItem
]
e:\work\!!!!!!!!!!!!!\OPCServer\DeviceHost\C_Device.cpp(66): error C2440: 'initializing' : cannot convert from 'T_RefStrong<P_Type>' to 'C_DeviceItem *'
with
[
P_Type=C_Device
]
e:\work\!!!!!!!!!!!!!\OPCServer\DeviceHost\C_Device.cpp(88): error C2440: 'initializing' : cannot convert from 'T_RefStrong<P_Type>' to 'C_DeviceItem *'
with
[
P_Type=C_Device
]
std::map<DWORD, T_RefStrong<C_Device_> >
Compiling...
C_Device.cpp
e:\work\!!!!!!!!!!!!!\OPCServer\DeviceHost\C_Device.h(9) : error C2065: 'C_Device_' : undeclared identifier
e:\work\!!!!!!!!!!!!!\OPCServer\DeviceHost\C_Device.h(9) : error C3203: 'T_RefStrong' : class template invalid as template argument for template parameter '_Ty', expected a real type
e:\work\!!!!!!!!!!!!!\OPCServer\DeviceHost\C_Device.cpp(23) : error C2440: '=' : cannot convert from 'int' to 'C_DeviceItem *'
Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast
e:\work\!!!!!!!!!!!!!\OPCServer\DeviceHost\C_Device.cpp(35) : error C2440: 'initializing' : cannot convert from 'int' to 'C_DeviceItem *'
Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast
e:\work\!!!!!!!!!!!!!\OPCServer\DeviceHost\C_Device.cpp(41) : error C2679: binary '=' : no operator found which takes a right-hand operand of type 'T_RefStrong<P_Type>' (or there is no acceptable conversion)
with
[
P_Type=C_DeviceItem
]
e:\work\!!!!!!!!!!!!!\OPCServer\DeviceHost\C_Device.cpp(66) : error C2440: 'initializing' : cannot convert from 'int' to 'C_DeviceItem *'
Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast
e:\work\!!!!!!!!!!!!!\OPCServer\DeviceHost\C_Device.cpp(88) : error C2440: 'initializing' : cannot convert from 'int' to 'C_DeviceItem *'
Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast
И трейсить можно если вдруг чего совсем не понял.
Tom>ЗЫ: В принципе если шаблоны упростят и так как нет множественного наследования, то не всё так плохо
И чего плохого в МН? А шаблоны не упращать надо, а развивать. И вобще типизированые макросы хочу!
... << RSDN@Home 1.0 beta 5 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, VladD2, Вы писали:
VD>Заметьте. Среди людей наезжающих на шаблоны (ну или пытающихся свести их достоинства только к увеличению производительности) все не имели большого опыта работы с шаблонами. А все кто успешно использовал шаблоны в С++ ждут их пояления в Шарпе. Это явно не спроста.
Жду очень жду.
ЗЫ Мой опыт С++ программирования говорит что шаболны сокращают обьем текста в разы, а читабельность и перформанс возрастают на порядок.
... << RSDN@Home 1.0 beta 5 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, WolfHound, Вы писали:
WH>ЗЫ Мой опыт С++ программирования говорит что шаболны сокращают обьем текста в разы, а читабельность и перформанс возрастают на порядок.
В С++. В шарпе такого сильного эффекта не будет, хотя в чем то съэкономить и получится.
Здравствуйте, AndrewVK, Вы писали:
AVK>Вот этого я и боюсь. Народ начнет по старой привычке лепить шаблоны даже туда где они нафик не нужны. Не думаю что с народом который ДЕЙСТВИТЕЛЬНО хорошо использовал такое произойдет.
... << RSDN@Home 1.0 beta 5 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, WolfHound, Вы писали:
WH> Не думаю что с народом который ДЕЙСТВИТЕЛЬНО хорошо использовал такое произойдет.
Хотелось бы надеятся, но практика показывает что если что то можно сделать неправильно то это обязательно сделают неправильно. Иначе к чему такие драконовские ограничения в джаве придумали.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, WolfHound, Вы писали:
WH>> Не думаю что с народом который ДЕЙСТВИТЕЛЬНО хорошо использовал такое произойдет.
AVK>Хотелось бы надеятся, но практика показывает что если что то можно сделать неправильно то это обязательно сделают неправильно. Иначе к чему такие драконовские ограничения в джаве придумали.
Хороший язык программирования (и платформа тоже) должны предоставлять ПОБОЛЬШЕ возможностей. А то нелогично получается... Ограничили всех, потому что те, кто чегой-то не доучил могут напортачить...
RSDN@Home
Кто здесь?!
Re[14]: Будут ли шаблоны и множественное наследование в CLR?
От:
Аноним
Дата:
21.02.03 09:56
Оценка:
Здравствуйте, _wqwa, Вы писали:
W>Хороший язык программирования (и платформа тоже) должны предоставлять ПОБОЛЬШЕ возможностей. А то нелогично получается... Ограничили всех, потому что те, кто чегой-то не доучил могут напортачить...
Неправда. Хорошая среда программирования вовсе не должна "предоставлять ПОБОЛЬШЕ возможностей". Она должна предоставлять возможности, потребные для решения круга задач, на которые она рассчитана, адекватно условиям, в которых эти задачи решаются. В прикладном программировании очень существенна технологичность — соответственно, многие возможности, скажем, Си++ остаются неиспользованными (и за использование их нужно расстреливать). В других задачах — наоборот, можно, как это уже здесь назвали, "творить чудеса на шаблонах и переопределяя операторы".
Re[14]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, _wqwa, Вы писали:
W>Хороший язык программирования (и платформа тоже) должны предоставлять ПОБОЛЬШЕ возможностей.
С такой точки зрения ассемблер идеальный язык, а скрипты не имеют права на существование. Но на самом деле это нетак. Следовательно предпосылка неверна.
Здравствуйте, <Аноним>, Вы писали:
А>Неправда. Хорошая среда программирования вовсе не должна "предоставлять ПОБОЛЬШЕ возможностей". Она должна предоставлять возможности, потребные для решения круга задач, на которые она рассчитана, адекватно условиям, в которых эти задачи решаются. В прикладном программировании очень существенна технологичность — соответственно, многие возможности, скажем, Си++ остаются неиспользованными (и за использование их нужно расстреливать). В других задачах — наоборот, можно, как это уже здесь назвали, "творить чудеса на шаблонах и переопределяя операторы".
И за какие это возможность С++ надо расстреливать???Поясни пожалуйса.
ЗЫ Представся
... << RSDN@Home 1.0 beta 5 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, _wqwa, Вы писали:
W>>Хороший язык программирования (и платформа тоже) должны предоставлять ПОБОЛЬШЕ возможностей. А то нелогично получается... Ограничили всех, потому что те, кто чегой-то не доучил могут напортачить...
А>Неправда. Хорошая среда программирования вовсе не должна "предоставлять ПОБОЛЬШЕ возможностей". Она должна предоставлять возможности, потребные для решения круга задач, на которые она рассчитана, адекватно условиям, в которых эти задачи решаются.
Звучит как: "возможностей не должно быть много, возможностей должно быть столько, сколько нужно для того, для чего нужно". Прям санскритская загадка.
А>В прикладном программировании очень существенна технологичность — соответственно, многие возможности, скажем, Си++ остаются неиспользованными (и за использование их нужно расстреливать).
Потрясающе! Это что же за прикладное программирование на некотором языке, где нельзя использовать возможности этого языка? Да ещё и под страхом смертной казни. Да, и если можно, то нельзя ли перечислить "нетехнологичные" для прикладного программирования возможности C++.
ИМХО, за неиспользование возможностей C++ (.Net, Java — нужное вписать), действительно, надо "расстреливать".
A>В других задачах — наоборот, можно, как это уже здесь назвали, "творить чудеса на шаблонах и переопределяя операторы".
По-вашему, "остальное программирование" не является прикладным? Очень интересно. Кстати, и что такое "прикладное программирование" в Вашем понимании?
Уважаемый Аноним, определитесь, пожалуйста, с семантикой терминов, которыми вы оперируете.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[15]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, _wqwa, Вы писали:
W>>Хороший язык программирования (и платформа тоже) должны предоставлять ПОБОЛЬШЕ возможностей.
AVK>С такой точки зрения ассемблер идеальный язык, а скрипты не имеют права на существование. Но на самом деле это нетак. Следовательно предпосылка неверна.
Не совсем. Возможностью(выделенное в цитате) я имел в виду и удобство проектирования(тут асм не совсем катит) и возможности настраиваемой кодогенирации (всеми здесь любимые шаблоны) и простота парсинга текста (перл) и освобождение от менеджмента памяти (ява, шарп) и т.д.
Очевидно, что не может быть языка со всеми этими (и другими) возможностями одновременно.
И ассемблер -- не идеальный язык (как Вы сами и догадались ).
Следовательно опровержение предпосылки несостоятельно.
Эту же задачу я мог бы решить следующим образом. 
Не думаю что с народом который ДЕЙСТВИТЕЛЬНО хорошо использовал такое произойдет.
