Почему реализация STL настолько нечитаема? Как С++ можно было улучшить здесь?

Ответ 1

В реализациях используются имена, начинающиеся с символа подчеркивания, за которым следует заглавная буква или два символа подчеркивания, чтобы избежать конфликтов с определяемыми пользователем макросами. Такие имена зарезервированы на С++. Например, можно определить макрос с именем Type, а затем #include <vector>. Если vector реализация использовала Type в качестве имени параметра шаблона, она сломалась бы. Однако нельзя определять макросы, называемые _Type (или __type, type__ и т.д.). Поэтому vector может безопасно использовать такие имена.

Ответ 2

Множество реализаций STL также включает проверку сборок отладки, таких как проверка того, что два итератора из одного и того же контейнера при их сравнении, и просмотр итераторов, выходящих за пределы. Это включает довольно сложный код для отслеживания контейнера и достоверности каждого созданного итератора, но он неоценим для поиска ошибок. Этот код также переплетается со стандартным кодом выпуска С#ifdefs - даже в алгоритмах STL. Поэтому никогда не будет так ясно, как их самая основная операция. Такие сайты, как этот, показывают самую базовую функциональность алгоритмов STL, заявляя, что их функциональность "эквивалентна" коду, который они показывают. Однако вы не увидите этого в ваших файлах заголовков.

Ответ 3

В дополнение к веским причинам, которые уже дали robson и AshleysBrain, одна из причин того, что стандартные версии библиотек С++ имеют такие краткие имена и компактный код, состоит в том, что практически каждая программа на С++ (блок компиляции, действительно) включает в себя большое количество стандартной библиотеки заголовки, и они, таким образом, повторно перекомпилируются (помните, что они в значительной степени основаны на шаблонах, в то время как заголовки стандартной библиотеки C содержат только несколько объявлений функций). Стандартная библиотека, написанная в стиле "стандартного стандарта", требует больше времени для компиляции и, таким образом, приводит к восприятию того, что конкретный компилятор "медленный". Минимизируя пробелы и используя короткие имена идентификаторов, lexer и parser имеют меньше работы, и весь процесс компиляции завершается немного быстрее.

Еще одна причина, о которой стоит упомянуть, заключается в том, что многие стандартные реализации библиотек (например, Dinkumware, Rogue Wave (старые) и т.д.) могут использоваться с несколькими разными компиляторами с очень разными стандартами соответствия и причудами. Часто бывает много макросов, предназначенных для удовлетворения каждой поддерживаемой платформы.