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

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

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

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

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

Вы не привыкли джентльменам верить на слово?

C's printf family of functions is an effective and often convenient I/O mechanism.
It is not, however, type-safe or extensible to user-defined types (classes and enumera-
tions). Consequently, I started looking for a type-safe, terse, extensible, and efficient
alternative to the printf family. Part of the inspiration came from the last page and
a half of the Ada Rationale [Ichbiah,1979], which argues that you cannot have a terse
and type-safe I/O library without special language features to support it. I took that as
a challenge. The result was the stream I/O library that was first implemented in 1984
and presented


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

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

Самой важной причиной является то, что stl криво спроектированная библиотека. В ней плохо практически все. Даже индекс и размер контейнера и тот умудрилось сделать unsigned создав программистам кучу проблем на ровном месте. Наличие совершенно бесполезных надуманных вещей таких как valarray выдает в ней академическую разработку, написанную для диссера или научной статьи. В качестве стандартной библиотеки языка эта экспериментальная разработка категорически не годится.


S>Третья причина -- это NIH синдром.
Знаете есть вещи хорошо сделанные, которыми приятно пользоватся и писать собственный велосипед желания не возникнет. stl напротив образчик плохого дизайна и анти-эстетики.

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

K>>

K>>//1
K>>class storage
K>>

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

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

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

И по вашему в том числе. Нотацию с префиксами вы сами забраковали постами выше, ну а класс storage в пространстве имен storage и комментариев не требует.

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

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

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

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

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

Мне трудно говорить с человеком который не понимает термин "опережающее описание (forward declaration)".

//Storage.h
struct Storage
{
    struct Blob
    {

    };
};

Класс Storage мы можем использовать без включения хедера Storage.h для этого нужно опережающее описание

struct Storage;
void foo(Stroage *stg);

С вложенным классом Storage::Blob такой номер не пройдет т.к. в языке С++ нет механизма опережающих описаний. Это баг уровня языка который нужно исправлять. Как бы вы тут не распинались, что это и не нужно.

struct Storage::Blob;
void foo(Storage::Blob *blob);

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

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

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

Ложечка хороша к обеду. Вы можете не дожить до того момента когда в С++ завезут все что нужно. Или С++ не доживет.
То с какой скоростью и как комитет проектирует этот язык напоминает издевательство. Было бы честнее либо заморозить С++ в актуальной версии и начать новый С++2.0 несовместимый со старым как это сделали в питоне, либо совсем отказаться от разработки языка объявив его deprecated. С моей точки зрения существующий труп смысла насиловать уже не имеет.


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

Эти литералы сделаны в угоду нескольким фрикам, которым не терпелось добавить в stl константы типа в минуте 60 секунд. В остальном это лишнаяя сущность и как обычно в традициях С++ совершенно беспомощная. Попбробуйте завести литерал Н/м^2 и не говорите что нинужно. Секунды завезли, а чем паскали хуже?