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

   С чего бы это?

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

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

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

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


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


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


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


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

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