Я знаю, что это очень поздно для вечеринки, но время меняется и ответы остаются. C ++ 11 имеет довольно широкие изменения, многие из которых должны повысить производительность C ++ и стандартной библиотеки. Похоже, что те, кто не использует STL или Boost, также не стремятся идти в ногу с новыми стандартами, в результате чего решения для домашнего прядения не нуждаются в важных улучшениях, конечно, это не всегда так.
Я использовал STL в каждом проекте с середины 90-х годов до сегодняшнего дня, за исключением короткого времени в EA. Я думаю, что анти-STL сторона имела несколько незначительных рациональных причин не использовать ее. Те в значительной степени ушли. Пользовательские распределители - это одно решение, использование резерва - другое, а не передача значения по значению - третье, но это довольно просто, и любой программист должен знать это. Более важно, хотя это использование алгоритмов. Авторы компиляторов точно знают, что делает for_each (), и могут оптимизировать код. Это не может произойти с домашним циклом. for_each () для объекта const еще лучше. Microsoft оптимизирует for_each во многих отношениях, включая сериализацию. У них также есть библиотека AMP, которая имеет parallel_for_each (). Если у вас есть шанс, поговорите с инженерами по компиляции об этом. Консольные компиляторы собираются оптимизировать то, что используется, так что Это проблема курицы и яйца. Microsoft идет очень тяжело с C ++ 11, и следующий XBox не будет отличаться. Я понятия не имею о PS4, мы еще не получили.
Пользовательские распределители - это один из способов решения проблемы с памятью, но другой (часто упускаемый из виду) вариант заключается в использовании новых и удаления на основе классов. Таким образом можно добиться значительного увеличения производительности.
Понятие, что Boost и STL имеют узкое представление о решении проблем, является чистым безумием. Я ошеломлен тем, как много вещей в STL и Boost можно настроить с помощью свойств и политик. Ищите сравнение строк без учета регистра в качестве примера.
Что касается продолжительного времени ссылок и раздувания кода, новый шаблон extern должен помочь в этом. Как правило, я нахожу, что длительное время компиляции происходит из-за избыточной связи и неправильного использования pch.
Самая веская причина для использования STL вместо homespun - миллионы людей, которые могут помочь вам с STL. Как всегда, не оптимизируйте преждевременно и тестируйте, тестируйте, тестируйте.