Собственно т.н. обобщенное программирование — в чем его глубокий смысл если тот самый
<some_type> который используется в шаблонах по сути есть базовый класс в ООП.

например непонятно зачем ломать голову как сделать сортировку один раз для всех типов поддерживающих это понятие когда можно выделить некий интерфейс ICompare у которого будут методы сравнения и все типы которые можно сравнивать и соотв-но сортировать должны поддерживать этот интерфейс. А в методе сортировки использовать непосредственно ссылку на интерфейс. Помоему такая реализация нагляднее и понятнее чем шаблонизация. Мож поэтому в первой версии .net шаблонов и небыло ? Там вроде как все типы — объекты.

Здравствуйте, Аноним, Вы писали:

А>Собственно т.н. обобщенное программирование — в чем его глубокий смысл если тот самый
А><some_type> который используется в шаблонах по сути есть базовый класс в ООП.

Хороший вопрос. Далеко не каждый задумывается об этом.
Обычно принято говорить, что ООП — программирование в терминах обьектов их состояния и поведения. Обобщённое же программирование, к примеру, оперирует алгоритмами как элементами программы если мы говорим о сортировке. И это ортогональные подходы. Скажем так, это могут быть как два способа которыми можно решить такую задачу в терминах С++, так и методики используемые для решения задачи совместно.

От части ты прав, в твоём понимании обобщённое программирование реализует статический полиморфизм, в этом дейстивтельно присутствует сходство с ООП. Но как бы полиморфизм хоть и является одним из столпов ООП, не является его синонимом, но лишь одной из сотавляющих.

Каков глубокий смысл? А фиг его знает Это один из инструментов позволяющий удобно писать хороший код. Удобная идеома программирования. Подход вдохнувший в C++ вторую жизнь, хотя появившийся далеко не в C++. На самом деле знания одного С++ для понимания обобщённого программирования недостаточно. Это надязыковая идеома и для хорошего её понимания желательно знать и другие языки пользующие её. Что впрочем с таким же успехом относится и к ООП.

А>например непонятно зачем ломать голову как сделать сортировку один раз для всех типов поддерживающих это понятие когда можно выделить некий интерфейс ICompare у которого будут методы сравнения и все типы которые можно сравнивать и все типы которые можно сравнивать и соотв-но сортировать должны поддерживать этот интерфейс

Честно говоря не понял что ты этим хотел сказать. В С++ есть такой интерфейс, называется operator <. Для большей гибкости обобщённый алгоритм сортировки имеет возможность задать специальный компоратор знающий как сравнивать обекты. Однако сам алгоритм сортировки к ООП отношения не имеет. Это просто алгоритм. В терминах ООП он мог бы быть реализован в базовом классе всех контейнеров и работать с элементами этих контейнеров через виртуальную операцию <, но это просто было бы медленно.

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

AC>Каков глубокий смысл? А фиг его знает Это один из инструментов позволяющий удобно писать хороший код. Удобная идеома программирования.
Сложно согласиться (мне) т.к. для меня лично изучение того же stl и понимание его принципов и методов использования, намного сложнее чем понимание ООП.

AC>Честно говоря не понял что ты этим хотел сказать. В С++ есть такой интерфейс, называется operator <. Для большей гибкости обобщённый алгоритм сортировки имеет возможность задать специальный компоратор знающий как сравнивать обекты.

Я хотел сказать что не обязательно даже придерживатся принципа наследования от некого базового класса CCompareableObject , а достаточно чтобы класс имел необходимый интерфейс ICompare
{
int Compare(CObject* withObject);
}

И алгоритм сортировки может принимать список интерфейсов ... не более того я хотел сказать

Здравствуйте, Аноним, Вы писали:

AC>>Это один из инструментов позволяющий удобно писать хороший код. Удобная идеома программирования.
А>Сложно согласиться (мне) т.к. для меня лично изучение того же stl и понимание его принципов и методов использования, намного сложнее чем понимание ООП.
Дык, а кто говорил что будет просто? Однако при наличии понимания, это очень мощный и удобный инструмент. Ты наверное просто на лиспе никогда не писал.

А>Я хотел сказать что не обязательно даже придерживатся принципа наследования от некого базового класса CCompareableObject , а достаточно чтобы класс имел необходимый интерфейс ICompare <....> И алгоритм сортировки может принимать список интерфейсов ... не более того я хотел сказать
Конечно, можно и так, только имеет свои минусы, и наверное свой большой плюс. Это всего лишь один из вариантов решения задачи.

Здравствуйте, Alexey Chen, Вы писали:

AC>Здравствуйте, Аноним, Вы писали:

AC>>>Это один из инструментов позволяющий удобно писать хороший код. Удобная идеома программирования.
А>>Сложно согласиться (мне) т.к. для меня лично изучение того же stl и понимание его принципов и методов использования, намного сложнее чем понимание ООП.
AC>Дык, а кто говорил что будет просто? Однако при наличии понимания, это очень мощный и удобный инструмент. Ты наверное просто на лиспе никогда не писал.

Ты знал !
Да я не писал на лиспе и даже не представляю что за язык такой.
Но все равно приходится кусать локти и грызть ногти почему есть stl но нет по ее образу и подобию sol — standart objects library , по аналогии хотя бы с дотнетовскими классами.

Здравствуйте, Аноним, Вы писали:

А>Собственно т.н. обобщенное программирование — в чем его глубокий смысл если тот самый
А><some_type> который используется в шаблонах по сути есть базовый класс в ООП.

А>например непонятно зачем ломать голову как сделать сортировку один раз для всех типов поддерживающих это понятие когда можно выделить некий интерфейс ICompare у которого будут методы сравнения и все типы которые можно сравнивать и соотв-но сортировать должны поддерживать этот интерфейс. А в методе сортировки использовать непосредственно ссылку на интерфейс. Помоему такая реализация нагляднее и понятнее чем шаблонизация. Мож поэтому в первой версии .net шаблонов и небыло ? Там вроде как все типы — объекты.


ООП опирается на семантику, а обобщённое программирование на синтаксис – весьма различные подходы. Обобщённое программирование стало активно развиваться после того, как стало ясно, что ООП не решает всех проблем проектирования. Если использовать только ООП, то зачастую необходимо или плодить интерфейсы или опираться на проверку типа во время выполнения. Оба варианта приводят к раздуванию и утяжелению кода, в то время как обобщённое программирование предлагает более ясный, надёжный и эффективный подход. Благодаря ортогональности этих подходов можно очень эффективно смешивать ООП и обобщённого программирования. Да, при изучении шаблонов есть трудности, но если их преодолеть, то мир предстанет в новом свете.

P.S. ИМХО, отсутствие нормальной реализации шаблонов в .net является одной из основных (и непреодолимых) проблем этой платформы.

Здравствуйте, Аноним, Вы писали:

AC>>Каков глубокий смысл? А фиг его знает Это один из инструментов позволяющий удобно писать хороший код. Удобная идеома программирования.
А>Сложно согласиться (мне) т.к. для меня лично изучение того же stl и понимание его принципов и методов использования, намного сложнее чем понимание ООП.

AC>>Честно говоря не понял что ты этим хотел сказать. В С++ есть такой интерфейс, называется operator <. Для большей гибкости обобщённый алгоритм сортировки имеет возможность задать специальный компоратор знающий как сравнивать обекты.

А>Я хотел сказать что не обязательно даже придерживатся принципа наследования от некого базового класса CCompareableObject , а достаточно чтобы класс имел необходимый интерфейс ICompare
А>{
А> int Compare(CObject* withObject);
А>}

А>И алгоритм сортировки может принимать список интерфейсов ... не более того я хотел сказать

В Java так и сделано, там есть Comparable интерфейс (ну у них выбора то и не было . При разработке STL требовалось не потерять производительность при обобщении алгоритмов, поэтому он весь такой шаблонизированный, вызов виртуальной функции значительно дороже вызова обычной функции. Шаблонами надо увлекаться в меру, иначе исполняемый файл разрастется, особенно при неправильном использовании. Я думаю вполне оправдано для простых методов, требующих большой эффективности использовать шаблоны, а для более высокоуровневых методов с большим кол-вом операторов использовать интерфейсы, тут уже скорость вызова будет ничтожной по сравнению со временем работы функции.

Здравствуйте, Аноним, Вы писали:

А>Собственно т.н. обобщенное программирование — в чем его глубокий смысл если тот самый
А><some_type> который используется в шаблонах по сути есть базовый класс в ООП.

А>например непонятно зачем ломать голову как сделать сортировку один раз для всех типов поддерживающих это понятие когда можно выделить некий интерфейс ICompare у которого будут методы сравнения и все типы которые можно сравнивать и соотв-но сортировать должны поддерживать этот интерфейс.

Два плюса в пользу шаблонов —
1) скорость. Вызов виртуальной функции может быть медленным и не заинлайнится. Для простого сравнения двух int это может быть критично.
2) типобезопасноть. Не надо приводить типы. Компилятор предупредит о несответсвии, если скажем в коллекцию Foo* попытатся положить Bar*. Или попытатся компаратором для Foo* попытатся отсортировать Bar*

Здравствуйте, Аноним, Вы писали:
А>Я хотел сказать что не обязательно даже придерживатся принципа наследования от некого базового класса CCompareableObject , а достаточно чтобы класс имел необходимый интерфейс ICompare
А>{
А> int Compare(CObject* withObject);
А>}

Да, вот только, в отличие от шаблонов, такая реализация позволят сравнить объекты Foo и Bar разных типов, либо требует run-time проверки типов...

Здравствуйте, Draqon, Вы писали:

А>>Я хотел сказать что не обязательно даже придерживатся принципа наследования от некого базового класса CCompareableObject , а достаточно чтобы класс имел необходимый интерфейс ICompare
А>>{
А>> int Compare(CObject* withObject);
А>>}

D>Да, вот только, в отличие от шаблонов, такая реализация позволят сравнить объекты Foo и Bar разных типов,

Дык, но это не только минус, но и обалденный плюс

Здравствуйте, Alexey Chen, Вы писали:

AC>Дык, но это не только минус, но и обалденный плюс
Угу.

bool Compare(void *pa, void *pb)
{
  return ((Foo*)pa)->name <  ((Foo*)pb)->name; //а передали Bar*. Приплыли.
}

Здравствуйте, _Winnie, Вы писали:

_W>bool Compare(void *pa, void *pb)
_W>{
_W>  return ((Foo*)pa)->name <  ((Foo*)pb)->name; //а передали Bar*. Приплыли.
_W>}

Шутите уважаемый? Изначально пример был совсем иной, но приведённый вами тоже имеет право на жизнь. Просто есть такая штука как область определённости функции, только очень многие нью-программеры об этом не задумываются, и предпочитают симантически-синтаксический оверхед. Принцип 'лучше перебдеть чем недобдеть', конечно, штука полезная, но иногда жутко монструозная.

ИМХО, конечно, но плюсы они как спички, в том смысле что не игрушки.

Здравствуйте, Alexey Chen, Вы писали:

AC>ИМХО, конечно, но плюсы они как спички, в том смысле что не игрушки.
Когда я писал менеджер памяти, то я об этом помнил. О байтах, о том, что скрывается за кастами, всякие оффсеты, нужный момент инициализации менеджера, рекурсивные вызовы выделения памяти(из-за сбора статистки в них). Или когда я делел аналог std::vector, только не с копирующе-убивающей семантикой, а с двигающей(

Но на С++ можно программировать по-другому.
Например, когда я фигачу игровой код. switch, case, if, вызвали метод, отсорировали по хитпойнтам, вызвали метод для каждого элемента контейнера. И тд. Ничего опасного и требующего внимания. И если что, компилятор заботливо надает мне по ушам. И мне не нужно заботится об InvalidCastException, меня нежно поправят на этапе компиляции. (ой, опять забыл break в case... ну ничо,

Здравствуйте, _Winnie, Вы писали:

_W>Здравствуйте, Alexey Chen, Вы писали:

AC>>ИМХО, конечно, но плюсы они как спички, в том смысле что не игрушки.
_W>Когда я писал менеджер памяти, то я об этом помнил. О байтах, о том, что скрывается за кастами, всякие оффсеты,
<....>
_W>Но на С++ можно программировать по-другому.
Конечно можно. И даже нужно, когда условия позволяют. Но С++ тем и хорош, что позволяет программировать очень по разному. И плюсы/минусы решения определяются не догматами, а конкретной задачей. То, что большой минус в одной задаче, может быть офигенным плюсом в другой. Это я всё к тому, что приведение строчки кода с фразай — посмотрите какая фигня получается — мягко говоря, странно.

Здравствуйте, archimag, Вы писали:

A>P.S. ИМХО, отсутствие нормальной реализации шаблонов в .net является одной из основных (и непреодолимых) проблем этой платформы.

Во-первых шаблоны в C++/CLI неотличимы от шаблонов в С++, со всеми их достоинствами и недостатками. Во-вторых дженерики в дотнете сделаны такими не из-за каких то проблем, а вполне намеренно, для того чтобы сделать их компилируемыми и совместимыми с КОП и нетовским дизайн-таймом.

Здравствуйте, _Winnie, Вы писали:

_W>Два плюса в пользу шаблонов —

Два возражения.

_W>1) скорость. Вызов виртуальной функции может быть медленным и не заинлайнится. Для простого сравнения двух int это может быть критично.

Ага. Но вот проблемы скорости можно решать привитием большего ума компиляторам. Ведь если цель вызова действительно меняется во время работы приложения, и темболее передается из внешнего модуля, то шаблоны тут не помогут. Будет та же косвенность. А если вызов локализован, то компилятор может с успехом устранить его переписав программу. Научные работы по этому направлению ведутся очень давно.

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

_W>2) типобезопасноть. Не надо приводить типы. Компилятор предупредит о несответсвии, если скажем в коллекцию Foo* попытатся положить Bar*. Или попытатся компаратором для Foo* попытатся отсортировать Bar*

Типобезопасность есть и в интерфейсах и в дженериках.


ЗЫ

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

Здравствуйте, archimag, Вы писали:

A>ООП опирается на семантику, а обобщённое программирование на синтаксис – весьма различные подходы.

Весма странное утверждение. Сможешь обосновать?

A> Обобщённое программирование стало активно развиваться после того, как стало ясно, что ООП не решает всех проблем проектирования.

И когда это было? Например, все динамически-типизированные языки обладают абсолютными способностями обобщенного программирования. Эти языки появились куда раньше ООП. Так что у тебя тут неувязочка.

A> Если использовать только ООП, то зачастую необходимо

А в чем проблема плодить интерфейсы?

A>или плодить интерфейсы или опираться на проверку типа во время выполнения.

Иногда да. Но причем тут ООП? Что в С или Паскале можно было написать код не требующий приведения типов но при этом работащий полиморфно и эффективно?

A> Оба варианта приводят к раздуванию и утяжелению кода, в то время как обобщённое программирование предлагает более ясный, надёжный и эффективный подход.

Обобщенное программирование, если им не пользоваться для извращений, всего лишь способ написания алгоритмов способных оперировать разными типами. Не больше и не меньше.

A> Благодаря ортогональности этих подходов можно очень эффективно смешивать ООП и обобщённого программирования. Да, при изучении шаблонов есть трудности, но если их преодолеть, то мир предстанет в новом свете.

Обобщенное программирование != шаблонам С++. Есть и дженерики, и динамические языки, и даже языки вроде Ocaml делающие типов при компиляции. Послдение два вообще не нуждающиеся в чем-то вроде анотирования типов. Так что это стереотипы.

A>P.S. ИМХО, отсутствие нормальной реализации шаблонов в .net является одной из основных (и непреодолимых) проблем этой платформы.

Комплексы все это, комплексы. Изучи то о чем ведешь речь, и поймешь, что ошибался.