Здравствуйте, Igor Trofimov, Вы писали:
S>> Я как собака понимаю С++ но не пишу
iT>Я тоже так думал, пока Александреску не почитал
отсюда вывод — читать такие книги вредно для самооценки и читать их не нужно.
как там в песне поется "I believe that beauty magazines promote low self-esteem".
"VladD2" <forum@rsdn.ru> wrote in message news:447891@news.rsdn.ru... > Здравствуйте, LaFlour, Вы писали: > > LF>НУ я к тому что зная шаблоныы С++ лехгко ли будет применить данные знания при переходе на женерик шарповый, или всеже прийдется кардинально переучиваться > > Лично мне даже не пришлось заглядывать в документацию. Дженерики в Шарпе очень похожи на С++, но проще и применимы кроме всего прочего еще и к делегатам и интерфейсам.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, LaFlour, Вы писали:
LF>>Насколько правила женериков для С++ отличаются/подходят к #-вым? LF>>Ну синтаксис и прочее что писал Алексадреску и Джосуттис, насколько они адекватны в свете #вых женериков?
VD>В МС++ будут поддерживаться как старые добрые шаблоны, так и дженирики полностью совместимые с дотнетом (и Шарпом в частности).
А так-же будет поддерживаться смесь templates & generics. Например:
template < template < typename > class T >
class TTC {...};
generic < typename T >
ref class GenC {...};
TTC< GenC > var;
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>>Но времена меняются и чистое ООП вытесняет такие подходы. Интересно посмотреть что будет с С++ через 3 года.
VD>Кто чего вытесняет? Как только в С++ появились шаблоны все больше и больше кода пишется с их использованием. Так что верным скорее будет обратное утверждение: Времена меняется, и чистый ООП вытесняется "такими" подходами.
S>> Главное принцип построения результирующего кода. В итоге происходит сначала формирование исходного кода на С++ а затем уже в машинный код. Получить машинный код можно и другими путями.
VD>А что на Дельфи или Шарпе можно пропустить этап "формирования исходнго кода"?
Можно применять уже скомпилированные пакеты или ассемБЛИ и на их основе делать новые классы.
S>> Готов выслушать аргументированное категоричное мнение отличное от моего.
VD>Для этого нужно сначало как следует аргументировать собственное мнение.
Аргументирую.
1. Этап Win32 завершен;
2. В Net шаблонов не будет или будет генерация новых классов из шаблонов может даже отдельной утилитой.
3. Дженерики намного удобнее шаблонов,т.к. ты пишешь в уже актуальном коде и есть ли смысл использовать громоздкие шаблоны при этом необходимо всегда иметь исходный код.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Я бы сказал расширяющаяя обычное понятие ООП. Т.К. неопределенные типы имеют право на жизнь за счет дополнительных параметров определяющие правило функционирования этих типов. Это намного лучше чем использовать нетипизированные указатели зная размер типа и приводя его к типизированной ссылке.
VD>Ничего они не расширяют. Это просто способ создания обобщенных алгоритмов. Не больше и не меньше.
S>> Только интеграция эта происходит на этапе компиляции
VD>Да. И учитывая возможности шаблонов это в некоторой степени оправданно. К тому же такова уж концепция С++. В нем почти все происходит в компайл-тайме.
S>>по сути являющиеся аналогом Copy-Paste-Replace только производимая компилятором.
VD>Гы. Если копи-пэст делает компилятор, то это уже называется повторное использование кода. Собственно джит делает почти тоже самое (особенно если учесть, что линкер в С++ выкидывает дублирующийся код).
S>>Но пообщавшись с Дженериками мне такой подход больше нравится и он единственный в объектном подходе в Net.
VD>Дело в том, что ты не достаточно "общался" с шаблонами. Они во многом гибче и производительнее. По сути дженирики решают две задачи: 1) повышают контроль типов в обобщенных алгоритмах, 2) повышают скорость кода. Так вот, тоже самое делают и шаблоны. Но они порождают потенциально более бытрый код, и ко всему прочему, позволют делать некоторые выкрутасы недоступные дженирикам. В свою очередь дженирики обладают свойствами компонентности и предоставлют такие фичи как дженерик-виртальные фукнкции, дженерик-делегаты и дженерик-интерфейсы. Этого уже нет в С++.
VD>Таким образом дженирики — это просто другая реализация тогоже подхода. Со своими плюсами и со своими минусами. Однако тот факт, что с помпщью шаблонов можно создавать более оптимизированный код, говорит о том, что пункт 2) (своего предназначения) шаблоны выполняют лучше дженириков. Будем надеяться, что в будущем это исправится (возможно уже в релизе).
S>> А плюс шаблонов только в скорости зс счет вызовов прямых (Inline) методов и прямого сравнения за счет перегрузки операторов. Выигрыш в итоге не принципиальный особенно в идеалогии Net.
VD>Пол смысла в дженикиках — это скорость. Как ты мог заметить, в некоторых случаях, дженирики работают в десятки раз быстрее чем аналогичные полиморфные алгоритмы. Вторая заслуга — это строгая типизация. Так она в обоих случаях на всоте. Разве что можно записать в плюс дженирикам то, что они обеспечивают копилт-ворд при редактировании.
Постараюсь объяснить мое понимание дженериков. Т.К. в Delphi нет шаблонов но нужно делать универсальные классы на неопределенных типах то я вводил переменные ссылки в которые затем передавались адреса реальных переменных с уже определенным типом в наследниках. Все операции с данным типом в базовом классе основывались только на размере и переменных — методов с передачей ссылок.
Но базовый класс определял весь код класса, а все дополнительные операции с типом определялись в наследниках с добавлением незначительного количества кода. При этом скорость падает всего в 2 раза по сравнению с интегерами а с другими типами разница небольшая, а с применением более оптимальных алгоритмов вообще были быстрее со стандартными классами.
Но это ООП в отличии от шаблонов где генерится новый класс для каждого типа.
Дженерики по своей сути это то что я делал раньше только с абстрактной типизацией на этапе конструирования класса.
Понимаю, что вызвал негодование огромного количества посетителей данного форума но это мое видение и моя позиция.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>>
S>>internal abstract class BTCustomLevel<K,V>
S>>
VD>Кстати, вместо abstract лучше использовать интерфейс:
VD>
VD>internal interface BTCustomLevel<K,V>
VD>
Дело в том что BTCustomLevel содержит общие поля для наследников и поэтому такой подход единственный.
А зачем городить интефейс если через наследование получаешь более оптимальную структуру класса ??? ООП однако.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
D>>А что на Дельфи или Шарпе можно пропустить этап "формирования исходнго кода"?
S> Можно применять уже скомпилированные пакеты или ассемБЛИ и на их основе делать новые классы.
Ну, это и в С++ можно. Есть же lib-ы, да и МС++ существует.
S> Аргументирую. S>1. Этап Win32 завершен;
Еще лет эдак 5-10 может протянуть. 5 так точно.
Ну, и к Шаблонам это отношение не имеет.
S>2. В Net шаблонов не будет или будет генерация новых классов из шаблонов может даже отдельной утилитой.
Открой МС++ и убидись, что в нем шаблоны использовать можно. В новых расширениях к МС++ идет речь о том, что разрешат наследовать менеджед-классы от шаблонов.
S>3. Дженерики намного удобнее шаблонов, т.к. ты пишешь в уже актуальном коде
Что бы эта фраза имела смысл нужно детерминировать выражение "в уже актуальном коде", так как что такое актуальный код не ясно.
S> и есть ли смысл использовать громоздкие шаблоны
Это не обоснованное утвержедение. Ничего грамоздкого в шаблонах нет. Громоздкость получается когда шаблоны используют не по назначению.
S>при этом необходимо всегда иметь исходный код.
Это конечно аргумент. Аргументом так же яляется и то, что дженирики в дотнете отвечают уловиям компонентного подхода (могут быть скомпилированы в отчуждаемый модуль). Но иного это не нужно. А вот возможности шаблонов очень даже нужны.
Я вот даже подумываю не залудить ли свою версию (расширенную) Шарпа. Добавить туда некоторые недостающие возможности и некую замену шаблонов С++ в виде кода времени компиляции с помощью которого можно будет генерировать код на базе иняормации о типах и внешних источников данных.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Serginio1, Вы писали:
S> Но это ООП в отличии от шаблонов где генерится новый класс для каждого типа.
S>Дженерики по своей сути это то что я делал раньше только с абстрактной типизацией на этапе конструирования класса.
Дженирики — это дженирики. Полиморфизм — это полиморфизм. То что ты можешь решать одну задачу обоими способами еще не значит, что спостобы идентичны.
Сходства у шаблонов с дженириками куда больше, чем с полиморфизмом. Полиморфизм иногода удобен и полезен. Но для реализации обобщенных алгоритмов куда лучше подходит именно дженерик-парадигма. Шаблоны и есть реализация этой парадигмы для плюсов.
S> Понимаю, что вызвал негодование огромного количества посетителей данного форума но это мое видение и моя позиция.
Да какой гнев? Просто забавно смотреть на зарождение очередного фанатизма.
Я реалист. И вижу что у джеририков проблем хватает. Скорее всего это возрастные проблемы и в будущем они будут устранены. Вот только задолбало ждать этоо долбанное будующее.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
S> Дело в том что BTCustomLevel содержит общие поля для наследников и поэтому такой подход единственный.
Так не нужно пихать данные в абстракции.
S>А зачем городить интефейс если через наследование получаешь более оптимальную структуру класса ??? ООП однако.
И ты еще рассуждаешь об ООП. Интерфейс — это чистая абстракция. Абстрактные класы нужно исключительно для создания частично реализованных классов. Если вдруг появлются такие извраты как у тебя — это верный признак неверного дизайна.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
D>>>А что на Дельфи или Шарпе можно пропустить этап "формирования исходнго кода"?
S>> Можно применять уже скомпилированные пакеты или ассемБЛИ и на их основе делать новые классы.
VD>Ну, это и в С++ можно. Есть же lib-ы, да и МС++ существует.
Это по поводу шаблонов, т.к.
VD>Что бы эта фраза имела смысл нужно детерминировать выражение "в уже актуальном коде", так как что такое актуальный код не ясно.
Актуальный код это когда компилятор уже знает расбросал код на составляющие при и ясны связи и типы в отличие от шаблонов где этот этап происходит на этапе компиляции.
И всвязи с этим сообщения об ошибках STL с объемом текста по 3 килобайта и целые книги о том, как надо правильно это сообщения понимать.
VD>Это не обоснованное утвержедение. Ничего грамоздкого в шаблонах нет. Громоздкость получается когда шаблоны используют не по назначению.
Громоздкость заключается в том, что для каждого класса генерится свой код. И при создание шаблона
нужно ориентироваться на конечный исходный код. Хотя это и не проблема при небольших классах но на огромных это может приводить к непредсказуемым ошыбкам. S>>при этом необходимо всегда иметь исходный код.
VD>Это конечно аргумент. Аргументом так же яляется и то, что дженирики в дотнете отвечают уловиям компонентного подхода (могут быть скомпилированы в отчуждаемый модуль). Но иного это не нужно. А вот возможности шаблонов очень даже нужны.
VD>Я вот даже подумываю не залудить ли свою версию (расширенную) Шарпа. Добавить туда некоторые недостающие возможности и некую замену шаблонов С++ в виде кода времени компиляции с помощью которого можно будет генерировать код на базе иняормации о типах и внешних источников данных.
Я лично ничего против шаблонов не имею и как генератор исходников на основании созданного шаблона был бы не против иметь. Иногда нужно дорабатывать под соответствующие типы и иметь возможность наследования. Чем больше инструментов тем только лучше.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Но это ООП в отличии от шаблонов где генерится новый класс для каждого типа.
S>>Дженерики по своей сути это то что я делал раньше только с абстрактной типизацией на этапе конструирования класса.
VD>Дженирики — это дженирики. Полиморфизм — это полиморфизм. То что ты можешь решать одну задачу обоими способами еще не значит, что спостобы идентичны.
VD>Сходства у шаблонов с дженириками куда больше, чем с полиморфизмом. Полиморфизм иногода удобен и полезен. Но для реализации обобщенных алгоритмов куда лучше подходит именно дженерик-парадигма. Шаблоны и есть реализация этой парадигмы для плюсов.
Есть очень много вещей где нужно совсещать и полиморфизм и
абстрактную типизацию и дженерики здесь очнь удобны, т.к. практически не отличается от обычного программирования.
Шаблоны тем или иным способом реализуются и в других языках через подстановку типа или Copy-Paste_Replace. Т.К. в С# есть перегрузка операторов то ручная реализация шаблонов достаточно тривиальная задача через исходный код, но для того чтобы не делать лишних телодвижений было бы неплохо иметь генератор исходников на основании шаблонов на уровне компилятора. S>> Понимаю, что вызвал негодование огромного количества посетителей данного форума но это мое видение и моя позиция.
VD>Да какой гнев? Просто забавно смотреть на зарождение очередного фанатизма.
Ну это не фанатизм а реальное удовольствие от дополнительных возможностей реализации собственных мыслей. Это простое проявление восторга.
VD>Я реалист. И вижу что у джеририков проблем хватает. Скорее всего это возрастные проблемы и в будущем они будут устранены. Вот только задолбало ждать этоо долбанное будующее.
Ничего наши дети точно дождуться и программировать будет каждый человек на планете, а не избранные как лет 15 назад.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Дело в том что BTCustomLevel содержит общие поля для наследников и поэтому такой подход единственный.
VD>Так не нужно пихать данные в абстракции.
Это почему. На самом деле объяви я их виртуальными с пустой реализацией все нормально??? И зачем мне общие поля переопределять в каждом наследнике???? S>>А зачем городить интефейс если через наследование получаешь более оптимальную структуру класса ??? ООП однако.
VD>И ты еще рассуждаешь об ООП. Интерфейс — это чистая абстракция. Абстрактные класы нужно исключительно для создания частично реализованных классов. Если вдруг появлются такие извраты как у тебя — это верный признак неверного дизайна.
S>>Дженерики по своей сути это то что я делал раньше только с абстрактной типизацией на этапе конструирования класса.
VD>Дженирики — это дженирики. Полиморфизм — это полиморфизм. То что ты можешь решать одну задачу обоими способами еще не значит, что спостобы идентичны.
Можно узнать, в чём же их принципиальное различие?
Ведь дженерик работая с переданным типом, обращается к вполне определённому подмножеству его методов/свойств. Назовём это подмножество интерфейсом, и скажем, что переданный тип реализует этот интефейс. А теперь передадим в бывший дженерик, а теперь обычный класс, это интерфейс — и получим то же самое. Не так ли? Ну да, теперь надо этот интерфейс ещё и описать. Но вряд ли это принципиальное отличие.
Тогда что же?
PS. Естественно, не имею ввиду простые типы. Использование шаблонов на них — действительно удобно.
Здравствуйте, mrhru, Вы писали:
M>Ведь дженерик работая с переданным типом, обращается к вполне определённому подмножеству его методов/свойств. Назовём это подмножество интерфейсом, и скажем, что переданный тип реализует этот интефейс. А теперь передадим в бывший дженерик, а теперь обычный класс, это интерфейс — и получим то же самое. Не так ли? Ну да, теперь надо этот интерфейс ещё и описать. Но вряд ли это принципиальное отличие. M>Тогда что же?
M>PS. Естественно, не имею ввиду простые типы. Использование шаблонов на них — действительно удобно.
Прежде всего это отсутствие приведения типа,т.к. C# нет reinterCast или как его там короче без проверки. А проверка томозит.
Кроме всего прочего работа с объектами в Net дорогое удовольствие и где это возможно нужно работать с Value типмаи http://www.rsdn.ru/Forum/Message.aspx?mid=415352&only=1
Здравствуйте, Serginio1, Вы писали:
S> Актуальный код это когда компилятор уже знает расбросал код на составляющие при и ясны связи и типы в отличие от шаблонов где этот этап происходит на этапе компиляции.
Понятнее не стало.
S>И всвязи с этим сообщения об ошибках STL с объемом текста по 3 килобайта и целые книги о том, как надо правильно это сообщения понимать.
Ну, сказки тут рассказвать не надо. Сообщения очень даже понятные.
S> Громоздкость заключается в том, что для каждого класса генерится свой код.
Тебя то это как трогает? Дженирики тоже для каждого вэлью-типа свой код генерируют. Только в рантайме. Ну, и что? Какое это имеет отношение к громоздкости кода? Здается мне, что ты плохо знаешь синтаксис шаблонов. Они по сути мало отличаются.
S> И при создание шаблона S>нужно ориентироваться на конечный исходный код. Хотя это и не проблема при небольших классах но на огромных это может приводить к непредсказуемым ошыбкам.
Какой конечный? Нет никакого "конечного" кода. Есть просто исходный код. Он и в Африке исходным кодом будет.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Serginio1, Вы писали:
S> Есть очень много вещей где нужно совсещать и полиморфизм и S>абстрактную типизацию и дженерики здесь очнь удобны, т.к. практически не отличается от обычного программирования.
Ну, продемострируй отличие от шаблонов при условии что весь код лежит в одной сборке.
S> Шаблоны тем или иным способом реализуются и в других языках через подстановку типа или Copy-Paste_Replace. Т.К. в С# есть перегрузка операторов то ручная реализация шаблонов достаточно тривиальная задача через исходный код, но для того чтобы не делать лишних телодвижений было бы неплохо иметь генератор исходников на основании шаблонов на уровне компилятора.
Раз тривиальная, то попробуй сделай.
S> Ну это не фанатизм а реальное удовольствие от дополнительных возможностей реализации собственных мыслей. Это простое проявление восторга.
Это он самый форменный и ничем не обоснованный.
S>Ничего наши дети точно дождуться и программировать будет каждый человек на планете, а не избранные как лет 15 назад.
Не что будут делать дети меня не трогает. Мне самому охота при комунизме пожить.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
* thriving in a production environment *
