Просто каждый инструмент предназначен для своего использования.
Это верно. Но в применении к STL (будем для определенности говорить о контейнерах: list, map, vector) это правило означает, что сфера ее применения исчезающе узка. Типичны две ситуации:
1) Структура данных настолько проста, что незачем привлекать ни одну громоздкую конструкцию из STL. Она описывается двумя-тремя функциями, которые настолько элементарны, что ошибиться в них невозможно. Ни о каких дополнительных сутках на реализацию говорить не приходится. Минуты.
2) Структура данных и теребуемые способы доступа к ней вроде бы похожи на одно из тех, что предлагается STL но реализации STL «чуть-чуть не хватает». Типичный пример: map с многопоточным доступом к нему. Если его попротектить одним локом, то это узкое место, на котором будет постоянно кто-то спать. Значит все равно надо писать такой map самому.
Кроме того, общность контейнеров диктует правило: данные отдельно, линки отдельно. Это значит, что при формировании структуры лишние аллоки, при доступе лишние дереференсы. Лишний дереф — это не так безобидно, как кажется. Это вовсе не только одна инструкция. Он снижает эффективность процессорного кэша. Также «положить» объект в контейнер — это всегда копирование, а иногда и не одно, что вообще абсурд, поскольку накладывает обязательное требование на объекты быть копируемыми, либо вынуждает класть в контейнер указатель, что означает еще один маллок и еще один дереф, Сконструировать же объект сразу где надо нет никакой возможности (плейсмент нью не предлагать).
Таким образом, все существенное в программе надо писать без STL. А несущественное можно вообще писать на чем угодно, хоть на перле, хоть на питоне и вообще сплавить смежнику.
Кроме того, этих реализаций STL наплодили массу и не смотря на то, что она «как бы стандартная» у каждой реализации свои тараканы. У вижаковой свои, у стлпорта свои, у гнутой свои. Это делает программу, плотно использующую STL, совершенно непереносимой, либо заставляет включать какую-то версию STL внутрь и таскать за собой.
Вообще, мои наблюдения показывают что очень многие проходят следующие стадии относительно STL:
1) Пионер-геройская. Фтопку STL, STL — это попсово, мы напишем себе свою шаблонную библиотеку. Крутую, с блэкджеком и шлюхами.
2) Многоопытная. Фтопку свои поделки, они все равно ничем не лучше STL. Будем везде использовать STL и от коллег потребуем того же. Каждый случай ее неиспользования требует веских аргументов.
3) Уж-не-знаю-как-обозначить. Фтопку STL (вторично). От нее одни проблемы, с лихвой перекрывающие все ее плюсы. Будем данные хранить так, как нам надо, а не как оно «стандарнтно». Пусть это будет стопиццот способов, но каждый из них уместен там, где используется.
). В том числе и при выборе компилятора, и операционной системы, и среды разработки. Я лично сижу на MSVC-2005, это официальная среда разработки в фирме, где я работаю, особых нареканий я к ней не имею, отладчик меня лично вполне устраивает. Пожелание "минимализма" приводит к тому, что время тратится на настройку системы и на то, чтобы заставить ее работать.
