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

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

К>>>У меня скорее претензии не к тому как написана эта книга. Написана она хорошо, и читается легко. Для самообразования, чтобы не закиснуть, прочитать полезно. Только вот зачем они, эти сложные вещи? Они кому-нибудь помогли в работе?
F>>конечно!!!
F>>1. многого стоит одна лишь структура Type2Type
F>>2. глава про стратегии вообще меняет подход к разработке кода, особенно библиотечного

К>Хотя умный указатель типа boost::shared_ptr мне кажется более жизнеспособным, чем предлагаемый Александреску policy-based указатель.
boost::shared_ptr не реализует стратегию многопоточности, а иногда необходимость в этом возникает...

К>Вот интересно, были ли применения за рамками библиотечного кода и если были, то какие?
К>Особенно интересует описанное в главах 3, 5-11. Насчёт глав 1,2,4 согласен, что они интересные и могут находить применения.
не помню главы по нумерации... в коммерческих проектах использовал Loki::SmallObject, Loki::SmartPtr, Loki::Singleton, Loki::Factory

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

F>Здравствуйте, Константин, Вы писали:

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

К>>>>У меня скорее претензии не к тому как написана эта книга. Написана она хорошо, и читается легко. Для самообразования, чтобы не закиснуть, прочитать полезно. Только вот зачем они, эти сложные вещи? Они кому-нибудь помогли в работе?
F>>>конечно!!!
F>>>1. многого стоит одна лишь структура Type2Type
F>>>2. глава про стратегии вообще меняет подход к разработке кода, особенно библиотечного

К>>Хотя умный указатель типа boost::shared_ptr мне кажется более жизнеспособным, чем предлагаемый Александреску policy-based указатель.
F>boost::shared_ptr не реализует стратегию многопоточности, а иногда необходимость в этом возникает...

К>>Вот интересно, были ли применения за рамками библиотечного кода и если были, то какие?
К>>Особенно интересует описанное в главах 3, 5-11. Насчёт глав 1,2,4 согласен, что они интересные и могут находить применения.
F>не помню главы по нумерации... в коммерческих проектах использовал Loki::SmallObject, Loki::SmartPtr, Loki::Singleton, Loki::Factory
более того, самописный класс string, реализованный с применением Loki::SmallObject, в gui-шном приложении, интенсивно использующем опрос контролов, возвращающих значение в виде строки не боле 64 байт, дал прирост производительности в 20-30 процентов. хотя именно в отношении класса Loki::SmallObject я испытывал наибольший скептицизм.

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

LVV>>1. Джоссатисс. Стандартная библиотека С++
I>Может быть у меня старое издание этой книги, но на странице 341 читаю про std::find:
I>

I>... returns the position of the first element in the range [beg,end) that has a value equal to value.

find тупо ищет заданный элемент в интервале. Если найден, то итератор указывает на него. Если не найден, то итератор равен end().
I>А на странице 411 про std::includes:
I>

I>... for each element in [searchBeg,searchEnd) there must be an equal element in [beg,end).

I>И кажется мне, что equal в первом предложение означает как бы не совсем то, что equal во предложении втором. Это только кажется?
А includes тупо проверяет, все ли элементы одного интервала входят во второй. Если все -то ок, если нет, то false.

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

I>>И кажется мне, что equal в первом предложение означает как бы не совсем то, что equal во предложении втором. Это только кажется?
LVV>А includes тупо проверяет, все ли элементы одного интервала входят во второй. Если все -то ок, если нет, то false.

Видимо я чересчур туманно выразился. Открытым текстом: equal в первом предложении означает x == y, equal во втором предложении означает !(x < y || y < x). Прошу привести ссылку на то место в книге Josuttis-а, где на это различие обращается внимание.

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

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

I>>>И кажется мне, что equal в первом предложение означает как бы не совсем то, что equal во предложении втором. Это только кажется?
LVV>>А includes тупо проверяет, все ли элементы одного интервала входят во второй. Если все -то ок, если нет, то false.

I>Видимо я чересчур туманно выразился. Открытым текстом: equal в первом предложении означает x == y, equal во втором предложении означает !(x < y || y < x). Прошу привести ссылку на то место в книге Josuttis-а, где на это различие обращается внимание.
Дома поищу.

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

I>Может быть у меня старое издание этой книги, но на странице 341 читаю про std::find:
I>

I>... returns the position of the first element in the range [beg,end) that has a value equal to value.

В русском переводе на стр. 340 написано так:

возвращает позицию первого элемента со значением value в интервале [begin, end).

I>А на странице 411 про std::includes:
I>

I>... for each element in [searchBeg,searchEnd) there must be an equal element in [beg,end).

В русском переводе на стр. 401 написано так:

для каждого элемента интервала [searchBeg,searchEnd) должен существовать равный элемент в интервале [beg,end)

ИМХО, нормально написано.

Открытым текстом: equal в первом предложении означает x == y, equal во втором предложении означает !(x < y || y < x). Прошу привести ссылку на то место в книге Josuttis-а, где на это различие обращается внимание.

Не нашел. Но видимо объясняется тем, что для inludes интервалы должны быть сортированы (b тогда можно сравнивать на больше-меньше), а find выполняет поиск в несортированной последовательности (годится только явное точное сравнение).

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

LVV>В русском переводе на стр. 401 написано так:

LVV>для каждого элемента интервала [searchBeg,searchEnd) должен существовать равный элемент в интервале [beg,end)

LVV>ИМХО, нормально написано.

Нормально, нормально. Просто x равный y означает здесь не x == y, а !(x < y || y < x). Всего-то.

LVV>Не нашел. Но видимо объясняется тем, что для inludes интервалы должны быть сортированы (b тогда можно сравнивать на больше-меньше), а find выполняет поиск в несортированной последовательности (годится только явное точное сравнение).

Ну конечно же, читатель сам должен догадаться.

Нет, серьезно, даже если рассматривать эту книгу как книгу для новичков, как можно до такой степени упрощать? Читатель может ведь получить ложное чувство того, что все понял и во всем разобрался, а потом и программировать в таком же духе, наобум. Или у автора договоренность с Мейерсом, чтобы оставить часть знаний для поднявшихся на следующую ступень посвящения?

PS. Из этой книги, вернее из ее предшественницы на немецком языке я узнал про STL в 1997 году. То есть скорее можно было бы ожидать, что мое субъективное пристрастное отношение к ней будет положительным. Ан нет, не сложилось. STL — да, Josuttis — нет.

PPS. Вот правильная книга.

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

I>PS. Из этой книги, вернее из ее предшественницы на немецком языке я узнал про STL в 1997 году. То есть скорее можно было бы ожидать, что мое субъективное пристрастное отношение к ней будет положительным. Ан нет, не сложилось. STL — да, Josuttis — нет.
Я использую как справочник.
I>PPS. Вот правильная книга.
Перевод тоже был. Но учить по ней невозможно. Еще более справочник, чем Josuttis

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

LVV>Я использую как справочник.
I>>PPS. Вот правильная книга.
LVV>Перевод тоже был. Но учить по ней невозможно. Еще более справочник, чем Josuttis

По чему же учить-то?

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

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

J>>И с чем ты там не согласен? Вроде все претензии адекватны.

I>С общей оценкой. Претензии адекватны, но это не ляпсусы как у Josuttis-а, а далеко не очевидные ошибки аналогичные, скажем, ошибкам стандарта.
Ничего не могу сказать, не читал.

You will always get what you always got
  If you always do  what you always did

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

I>>С общей оценкой. Претензии адекватны, но это не ляпсусы как у Josuttis-а, а далеко не очевидные ошибки аналогичные, скажем, ошибкам стандарта.
J>Ничего не могу сказать, не читал.

Претензии-то там, на странице, ссылку на которую ты дал:

The most unsatisfactory thing about the book is that its contents deviate from what the Standard says and, what is dangerous, it authoritatively miss-states things. For example the book claims that

1. "For all the container classes defined by STL, if an exception is thrown during calls to the following member functions insert (single element insert), push_back, push_front the container is left unaltered and the exception is rethrown". Whereas the C++ Standard gives such strong guarantee for the overloaded member functions insert of classes vector and deque only on condition that the copy constructor and the copy assignment operator of the type T used to instantiate the container do not throw while inserting, see 23.2.1.3/2 and 23.2.4.3/1 of the Standard.

2. "For all the container classes defined by STL, no exception is thrown during calls to the following member functions erase (single element erase), pop_back, pop_front". Again the book fails to acknowledge that the C++ Standard gives the no-throw guarantee for the overloaded member functions erase of classes vector and deque only on condition that the copy constructor and the copy assignment operator of the type T used to instantiate the container do not throw while erasing, see 23.2.1.3/6 and 23.2.4.3/5 of the Standard.

The above over-confident statements could be partially justified, had the STL part of Dinkumware's Standard C++ library presented in the book delivered what the book claims. But, having studied the code of vector and deque, I can say that is not the case.

3. "The member function swap makes additional promises for all container classes defined by STL the member function throws an exception only if the container stores an allocator object al, and al throws an exception when copied". That's another mistake, for the Standard promises something completely different "no swap function throws an exception unless that exception is thrown by the copy constructor or assignment operator of the container's Compare object" (23.1/10).