Stl: в чем плюсы шаблонов?

Во всем. На буст посмотри.

  

они классные  

Что значит в чем плюсы? Шаблоны - это полиморфизм времени компиляции. Плюс в том что грамотно используя шаблоны можно избежать написания лишнего кода (т.е. возложить эту обязанность на плечи компилятора)

Это сообщение отредактировал(а) azesmcar - 26.5.2009, 21:14

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

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

Тупой вопрос...    
А в чем минусы? 

 

плюсы в кошерности.

зы. ыыы.

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

а когда пишешь разный код для разных типов не растет?

а зачем писАть разный код для разных типов?   

 

Добавлено через 2 минуты и 3 секунды
Минус в том, что если нет инстанцирования шаблона, то компилер не будет проверять его синтаксис.

вот за этим

список может хранить указатели на большие объекты, в то время как маленькие объекты можно хранить по значению
предложи такую реализацию списка(без шаблонов), которая будет работать так-же как в данном примере

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

вот именно синтаксис он и будет проверять для всех шаблонов(правда visual studio это не делает)

Это сообщение отредактировал(а) Lazin - 27.5.2009, 09:23

Растёт - но ты сам видишь что растёт, и чтобы он не рос принимешь меры, например для двух разных типов создаёшь обший базовый класс и переносишь общий код в него. А при применении шаблонов можешь об этом и не задумываться.
Например, нужен тебе список для хранения типов A, B, C, D, E, F ...
Ты пишешь:

Код шаблона list размножился 6 раз
А в этом слечае:

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

Это сообщение отредактировал(а) math64 - 27.5.2009, 09:29

не делает  

Добавлено через 3 минуты и 45 секунд
А если функция может использовать только один тип данных, стоит ли использовать шаблон?

с чего ты это взял? будут точно так-же созданы N реализаций шаблона  

Иногда стоит - если ты эту функцию объявил, но не используешь в данном проекте, то она не будет включена в исполняемый файл.
А если функция обычная, то она будет всегда включена в исполняемый файл, даже если не нужна (если файл с функцией исключить нельзя, поскольку в нём есть нужные функции и он используется в другом проекте, где все функции нужны)

нет, какой смысл в шаблоне, если все-равно будет только один вариант функции?

Я сказал: основной код шаблона не размножается. Большинство методов будет взято из базового класса или будут inline-методами,
вызывающими метод базового класса с кастингом аргументов и результата. Фактически размножатся только конструктор и деструктор.

Она же не будет включена в исполняемый файл.

Из книжечки "Программирование на С++". Коплиен


main.cpp

List.h

Set.h


Это сообщение отредактировал(а) zim22 - 27.5.2009, 10:20

  Есть и минусы, шаблон это общее решение. Общее решение всегда не быстрее грамотного частного решения. Шаблон должен использовать только общие возможности всех типов для которых он предназначен, тогда как специальный класс может использовать все возможности того типа с которым он работает.
  Для сравнения создайте вектор, например из 1024 байтов и добавьте еще элемент так чтобы было перераспределение и сделайте аналогичные операции руками при помощи new для выделения памяти/memcpy для копирования элементов/memset для инициализации нулями. Думаю скорость будет выше раза в два.

  Кто она? Код ф-ии?  А куда он денется?

бессовестная ложь  

Это верно. Однако, не следует преждевременно оптимизировать - во всяком случае, раньше, чем профилировщик и/или пользователи не обратили ваше внимание на низкую производительность.

Готовый шаблон из STL нужно - только использовать. Собственный вектор - нужно сначала написать, потом отладить, убедиться в отсутствии ошибок (написать юнит-тесты хотя бы), и только потом - использовать. Скорость разработки зачастую является более значимым фактором, чем потеря 1-2% производительности приложения в целом, которых никто не заметит.

Это сообщение отредактировал(а) Cтpaнник - 27.5.2009, 10:27

с это чего вдруг?  

после инстанциирования, алгоритм работы вектора сведется к тому, что квалифицированный программист может написать вручную, лишних действий там выполняться не будет
для некоторых параметров многие шаблоны специализированы, к примеру специализация std:swap для векторов не копирует элементы, а просто меняет местами указатели, или vector<bool> на самом деле не вектор элементов типа bool 

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

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

Добавлено через 11 минут и 26 секунд

нет!  
Alexis - не понимает о чем он говорит, его представление о шаблонах заканчивается на параметризированых типах, a-la дженерики в .NET. С помощью шаблонов можно делать намного больше и не платить за это уменьшением производительности. Некоторые идиомы с++ вообще не реализуемы без шаблонов.

  Проведите исследование, зайдите под дебагом в код. При копировании байтиков что будет делать вектор? Использовать 8 бит своего регистра, предварительно очищать верхнюю часть регистра, короче будет порядка 4-5 ассемблерных операций на перенос всего одного байта, тогда как memcpy возьмет цельный регистр разрядности процессора закинет в него сразу 4 элемента (8 элементов) и за одну операцию перекинет его в другой участок памяти. А если глянуть на код наращивания так вообще диву даешься. 
  В том то и дело, что счет идет не на 1-2%, а на 100-200%


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

Опять-же, бессовестная ложь  
Посмотри что получится в релизе, с оптимизациями и отключенными runtime проверками. И чем тебе не нравится код наращивания?


я привел пример  

непременно проведу..но вы сперва скажите какая из реализаций СТЛ ведет себя так а то я подозреваю что на нее наткнутся будет весьма сложно.  

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

и


это дело того - кто реализовывал СТЛ. Стандарт не требует вызывать копи-конструкторы во время наращивания вектора, следовательно можно реализовать это и с помощью memcpy.

VC++ 2008: один и тот же код (с шаблонами и без них), релиз версия - ехе-шники весят одинаково!!!
Получается, что компилер "вырезал" (в exe-шнике без шаблонов) лишний код....

Это сообщение отредактировал(а) Alca - 27.5.2009, 11:51

  В стандарте сказано что вектор штука пипец какая универсальная, и должна работать хоть на 8ми битном проце, хоть на 64х разрядном на любой ОС и на любом компиляторе. Поэтому код копирования будет примерно таким

  Не нужно слепо верить в возможности оптимизатора, он не настолько умный, чтобы из этого сделать memcpy(newbuf, oldbuf, oldsize);

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

  В PE модуле секции выравниваются, минимальное выравнивание 512 байт.

Вот Вам условный код, показывающий возможности шаблонов для выбора подходящей реализации


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

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

Не сваливайте проблемы неправильного проектирования на шаблоны.

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

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

Ну как бы еще можно boxing заюзать ;)
И код не будет дублироваться )

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

  Покажите мне современный компилятор у которого реализация вектора работала указанным выше обазом.

  Поэтому чего бы вы не говорили, за скорость минус. Минус не жирный (сложность алгоритмов не меняется), но все таки минус.

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

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


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

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

любой современный.

вот смотрите на участок кода произвольной стл,  и обратите как из вызова copy получается __copy_trivial  в случае подоходящего типа  
и как в одних случаях применяется цикличность, а в других memmove.

 

Надеюсь после рассмотрения вышеприведенного кода, Вы откажетесь от этих слов 


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

у многих стл в частности для инициализации памяти однобайтовых pod последовательностeй, вызывается  std::memset. 


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

   С чего бы это?

  Читайте внимательно. 

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

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

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


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


Быстрее, чем это возможно ?! а это не входит в список его задач и  никто кроме Вас и не требует  
К тому же этого не может и Ваш частный случай.


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


А это вобще непонятно к чему Вы сказали..

Шаблоны без параметров бывают?

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

выгляд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'ов и т.п.

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

критика у вас какая-то примитивная, вот к примеру Александресску делает это правильно, он говорит что концепция итераторов не верна и вместо этого нужно использовать концепцию диапазонов(ranges), это позволило-бы сильно упростить код а так-же добавить функции, которые сейчас сложно реализуемы, например проверку корректности итераторов без падения производительности. С таким дизайном STL как сейчас проверка валидности итераторов(если ее включить) заметно снижает производительность.
Я бы еще хотел что-бы в STL была реализована концепция views. Это что-то вроде алгоритмов, в общем я хотел-бы иметь возможность писать так:

В общем, view это что-то вроде контейнера, элементы которого не хранятся в нем, а вычисляются по требованию. Это позволит реализовать ленивые вычисления в стиле STL, что иногда бывает необходимо. К примеру, когда loooong_sequence не просто контейнер, а сложный объект, который загружает данные по требованию, или когда нельзя загрузить все данные полностью(loooong_sequence это istream_iterator большого файла, который не помещается в память полностью), либо когда последовательность loooong_sequence - бесконечна, а вся логика приложения реализована в функторах, переданных в view.

Эту тему нужно повесить в вики)))
Вот. Читаю, учусь.

У каждой профессии запах особый  


не совсем понятно о чем речь. 


обычно чтения докумментации по поведению того или иного класса должно быть достаточно. Если библиотека не соответствует своему описанию - это проблема разработчика библиотеки.

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

Это сообщение отредактировал(а) azesmcar - 28.5.2009, 09:00

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

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

  Думаю смысл в том что все новомодные фичи еще плохо обкатаны, поэтому не стоит торопиться их лепить везде и сразу, поскольку компиляторы пишут тоже люди, которые совершают ошибки. Но шаблонам уже лет 15-20 как минимум, так что основные фичи работают стабильно, нельзя сказать что сами шаблоны нестабильный механизм.

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


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


а если полностью разобраться во внутренностях буста, то все вообще будет отлично 

Это сообщение отредактировал(а) Alek86 - 28.5.2009, 09:55

на данный момент это будет сложно - так как для буста практически нет книг, плюс он динамически растет и меняется. Он не вошел в стандарт, потому пока что никаких точных данных вам никто не предоставит. А вот с СТЛ такой проблемы нет. Он стандартиризован. Будут несоответствия - кройте матом производителя.  

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


Это сообщение отредактировал(а) mes - 28.5.2009, 09:52

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

насчет кривых реализаций -

в MSVC2008 при разыменовании e чтобы проверить границы контейнера
в релиз версии используется assert(this<end()) 
в дебаг версии используется assert(this<_Mylast) , где _Mylast - значение end() сохраненное при создании итератора

в результате прога нормально работает в релизе и падает при попытке отладить