бывают, только трудно подобрать задачу где такое было бы необходимо.

выглядeть будет например так :




Это сообщение отредактировал(а) mes - 27.5.2009, 21:26

Позвольте привести еще пару плюсов за использование шаблонов:
1) Тут Алексис упомянул, что обобщенный код не может быть лучше\быстрее чем код, заточенный под конкретный случай. Это, канешна, так, если речь идет о т.н. "идеальном программисте". А идеальный программист - это что-то вроде сферического коня в вакууме... не думаю, что в данном обсуждении найдется много товарищей, сумеющих написать код так же грамотно, как это сделано в STL (ну, не будем брать тривиальные примеры типа memset...). Короче, используя готовые шаблоны, вы используете грамотный код, до которого еще додуматься нужно. Я уж не говорю о том, что этот код доступен для изучения и повышения квалификации...
2) Пример  совсем из другой оперы. Представьте, что есть достаточно сложный и широко используемый класс. И вот в недрах реализации этого класса нужно реализовать некоторую функцию (чисто для имплементации) над, скажем, хранимым в классе контейнером. И тип этого контейнера объявлен как private. И тип его элементов тоже. Можно, канешна, написать private функцию и добавить ее в интерфейс многострадального класса. Но как уже было сказано, класс и так достаточно сложный. А функция ерундовая и достаточно общая, типа for_each или find (и нужно таких 5 и все немного разные). И делать ее другом ради доступа к private-типу совсем не хочется. Да и вообще упоминать в интерфейсе тоже. Выход - пишем шаблон с обобщенным контейнером, в безымянном пространстве где-нибудь рядом с местом использования. Сплошные плюсы: инкапсюляция не нарушается, интерфейс не засоряется, код не увеличивается...

плюсы примерно те же, что и в случае секса с девушкой против собственой руки.

а если девушка крокодил?

К шаблонам это не относится

Почему не относится ? Среди шаблонов также бывают крокодилы, как и в любом другом коде.
Но вот девушка-стл гораздо опытнее, красивее и безопасней, чем многие самописанные.  

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

Вы это об идеале ? или о том, что компилятор плохо справляется со своей работой ( речь о шаблонах) и лучше освободить его от этого и повесить эту работу на программиста ?

Это сообщение отредактировал(а) mes - 27.5.2009, 21:35

но он ошибается реже...



имелось ввиду что шаблоны - это не семейство крокодилов  

у меня складывается впечатление, что ты думаешь о шаблонах, как о компонетах в delphi, я лично не понимаю как такое может быть, приходит заказчик и говорит: "у вас там в качестве параметра шаблона для std::list используется класс Foo, так вот у него нужно убрать конструктор копирования и оператор присваивания"  


в этой ситуации и проявятся приемущества правильно написаного шаблона, код который работал с 4-мя категориями, может без изменений заработать с 12-ю.  


пример из жизни, шаблон boost::fusion::vector<int, long, double> на самом деле реализован точно так-же как эта структура 

, и почему шаблон должен работать "не так", если он в итоге раскрывается в такую-же точно структуру?
Здесь дело не в шаблонах. Если ты будет писать библиотеку и в ней будет обычный класс - динамический массив, для определенного типа данных. Этот класс будет универсальным, так как ты не знаешь где и как будешь его использовать. Поэтому он будет работать не так как код, специально написаный для определенного случая. Потому-что он универсальный.
С классами из STL то-же самое, они иногда работают "хуже" чем код заточеный под определенный случай, не потому что они шаблонные, а потому что они универсальные. 

Добавлено через 2 минуты и 54 секунды

а потому что нечего применять статический полиморфизм, там где нужно применять динамический  

Чувствую смрад религиозной войны.  

  А вот еще из минусов, чуть не забыл, код шаблонов объемней, сложнее как структурно так и сложнее для понимания по сравнению с кодом класса реализующего тот же функционал для заданного типа.
  azesmcar, почему смрад? Какашкокидальства не ожидается. Перечисляем все плюсы и минусы.

а не кажется ли Вам что сравнение немножко однобокое ? сравнивать надо не только усилия затраченные на разработку, но и пользу извлекаемую из использования.
Если выгоды нет, то зачем усложнять код ?!  Но если посмотреть например на стл, то сразу видно, что усилия разработчиков с лихвой окупились удобством и качеством  для пользователей.

запах победы!  

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

думаю тут уже говорили о том минусе, что реализацию шаблона из ашника нужно держать в ашнике...

еще минус - при их серьезном использовании вылазят такие ошибки компилятора, о которых и не догадывался. причем иногда (в случае VS 2005 очень редко, но метко), это ошибки именно компилятора, когда он действует не по стандарту

и еще - если один из программистов в команде хорошо разбирается в шаблона и пишет много кода с помощью их, traits'ов и стратегий, то:
1. остальные, кто не так хорошо разбирается в шаблонных заморочках при любой багфиксинге в том коде будут почем материть автора
2. если автор еще не выработал стиль в написании стратегий, helper'ов и т.п., то через месяц при багфиксинге в том коде он сам будет биться головой о стенку

также минусы стл и буста прочувствуются, когда программа будет вести себя не так, как ожидалось и нужно будет продебажить их внутренности. конечно, на 99,999% ошибка будет не в стл иди бусте, а у самого программиста, но поиск этой ошибки будет лежать через сплошные тернии шаблонов, traits'ов и т.п.

но это неизбежное зло. лично я лучшей альтернативы пока не встречал