Здравствуйте, Kluev, Вы писали:

S>>Цитату бы.

K>Это было в книге Страуструпа "язык С++" или "дизайн и эволюция С++" точно не помню.

Т.е. вместо цитаты опять нужно полагаться на ваши слова.

S>>Если вы не в курсе, то STL допиливался до состояния, в котором его приняли в стандарт, несколько лет. И в 1996-1997-ом годах свободные реализации STL (вроде бы от RogueWare) уже активно использовались в продакшене.

K>Если вы не в курсе от раннего stl-мазохизма в продакшене активно отказывались и пересаживались на собственные разработки. Это уже веский повод не торопится с добавлением такой сомнительной библиотеки.

В курсе. Даже в курсе причин, по которым это происходило. Самой важной из которых была отсталось большинства тогдашних компиляторов. Поэтому если нужно было делать что-нибудь серьезное и переносимое, то до начала 2000-х собственные велосипеды были самым надежным способом. Только это не потому, что STL плохой, а потому что многие компиляторы даже слова template не понимали. А из тех, что понимали, понимать могли по-разному.

Вторая причина, по которой от STL (или кусков STL) отказываются до сих пор -- это то, что нельзя сделать универсальный инструмент, который эффективен всегда. Поэтому в каких-то конкретных условиях нужно предпочесть что-то стороннее функционалу из STL (яркие примеры std::unordered_map и std::regex).

Третья причина -- это NIH синдром.

K>Смотрите сами. Простой пример:

K>

K>//1
K>class storage
K>{
K>    class blob
K>    {
K>    };
K>};

K>//2
K>namespace storage
K>{
K>    class storage;
K>    class blob;
K>}

K>//3
K>class storage;
K>class storage_blob;

K>

Простите, а это пример чего? Почему я должен думать, что все эти описания равноценны? Если вы считаете, что второй вариант является аналогом первого, то вы что-то делаете явно не так и в первом варианте нет смысла вкладывать blob в storage.

K>Из всех видов описаний только описание через вложенный класс storage::blob самое нормальное и естественное

Сразу уточним: нормальное и естественное по вашему мнению. Которое можно смело отправлять в /dev/null на основании тех перлов, которые вы наговорили ранее.

K>Но для вложенного класса нет опережающего описания и его потребуется всегда включать через #include.

Э... Простите, а как же тогда классический pimpl работает?

class A {
   struct impl;
   std::unique_ptr<impl> impl_;

private:
   ~A();
   ...
};

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

K>Когда у вас в языке нет:
K>рефлексии
K>модульности
K>оператора возведения в степерь
K>нет стандартной формы библиотеки, т.е невозможно организовать стандартные репозитарии библиотек как в других языках
K>и т.д и т.п.

K>на фоне вот этих вопиющих дыр полный бред тратить усилия на такие бесполезные параши как литералы.

Только на моей памяти:

* в C++ не было ни исключений, ни пространств имен, ни шаблонов;
* в C++ не было ни шаблонов с переменным количеством параметров, ни лямбда-функций, ни move-semantic-и, ни регулярных выражений;
* в С++ не было ни модульности, ни рефлексии, ни менеджера пакетов...

Вы сами можете подставить в этот список отметку "сейчас мы здесь". И можно со 100% уверенностью сказать что когда в C++ завезут модули, рефлексию, сильно обогатят стандартную билиотеку и в конце-концов выживет всего один де-факто стандартный менеджер пакетов, то персонажи вроде вас все равно будут перечислять то, что им должны обязательно дать вот прямо сейчас и бесплатно просто по праву того, что они соизволили обратить свой взгляд на C++.

По поводу литералов: если они вам не нужны (или вы ими не пользуетесь) ну так и не пользуйтесь. Зачем поливать говном то, что облегчает жизнь другим C++ разработчикам?