критика у вас какая-то примитивная, вот к примеру Александресску делает это правильно, он говорит что концепция итераторов не верна и вместо этого нужно использовать концепцию диапазонов(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() сохраненное при создании итератора

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

Ваш код потенциально опасен. 



Для того, чтоб  resize не вызвал переаллокацию памяти я предполагаю, что Вы удостоверились, что capacity не меньше new_size.
Ваш итератор не находится before the insertion point, а следовательно он не валиден.

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

потому и сказал

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

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

к счастью многих на нормальном компиляторе стандартные контейнеры такого не допустят.   


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

Из книжечки Мэтью Улисона "Практический подход к решению проблем программирования С++" (стр.483)

  Моск взорвался   

прочитайте лучше в книжечке. там страниц 10-20 об этом написано. я всё не могу набирать 

Давайте рассмотрим класс String:


Мы можем использовать его с текущим определением Wrapper таким образом:
(примечание от меня: какое определение было текущим я не знаю, поэтому приведу оба)
1 определение Wrapper:

2 определение Wrapper:

Использование Wrapper:

Конструкторы компилируются нормально, и программный код работает так, как ожидается, но имеется скрытый недостаток. Выполнение конструктора s2 приводит к созданию двух копий строки ss там, где мы ожидали и хотели получить лишь одну. Дополнительная копия создается, т.к. компиляторы инстанциируют шаблон на основе передаваемых ему типов аргументов без учета того, как они могли бы использовать внутри него. Таким образом, выполняемая работа по созданию s2 фактически эквивалентна следующему:

Это и есть дефект.