Formal review of the Smart Container library

http://lists.boost.org/MailArchives/boost/msg72134.php
(boost.devel 2004/09/26~)
ぎゃーす!!Smart Containerのレビューが始まってるぅ!!完全に見落としてたー!!

Whenever a programmer wants to have a container of pointers to heap-allocated objects, there is usually only one exception-safe way: to make a container of smart pointers like boost::shared_ptr. This approach is suboptimal if
  1. the stored objects are not shared, but owned exclusively, or
  2. the overhead implied by smart pointers is inappropriate

うん.これは納得.

The advantages of smart containers are
  1. Exception-safe and fool proof pointer storage and manipulation.
  2. Notational convenience compared to the use of containers of pointers.
  3. Can be used for types that are neither Assignable nor Copy Constructible.
  4. No memory-overhead as containers of smart pointers can have (see 11 and 12).
  5. Usually faster than using containers of smart pointers (see 11 and 12).
  6. The interface is slightly changed towards the domain of pointers instead of relying on the normal value-based interface. For example, now it is possible for pop_back() to return the removed element.

1は実際にコンテナを自作してみないとなかなか分からないかも.valueの連続領域を持ってるvectorやdequeはinsert/erase等を(強い)例外安全に作れないんですよね.
2はどうもbegin()がindirect_iterator返したりするのを指しているみたいだけれど,これってinterfaceの一貫性が取れてるんだろうか?
3は正直「うえぇ?」な感じなんだけれど・・・出来るの?
4,5は言わずもがな.所有権を共有しないのにsmart_ptr使うのは「鶏を割くにいずくんぞ・・・」ってわけで.
6これも出来るの?

boost::ptr_vector<Foo> vec;
vec.push_back( new Foo );
vec.begin()->bar();

push_backするのはポインタで,イテレータはindirect?にゅ〜ん・・・

This isn't so much a review of the Smart Container library, as it is a commentary on how this work relates to move semantics, which isn't practical in C++03 (I used to say not possible). I do not mean to comment one way or another on the Smart Container library except to say that I know it addresses a real need, and I agree this may be the best way to meet it in C++03 (yes, I did read through the docs, nice job Thorsten! :-) ).

In C++0X I anticipate that this need will be met with container> (aka container>; I'm experimenting with naming alternatives to move_ptr, so please cut me a little slack! ;-) ).

やっぱそうだよなぁ.長い目で見るとMove Semanticsに基づく標準とSTLの再整備が本質的な方向性であるべきだと漏れも思うんだけどなぁ・・・.
あー,っていうかClonableとかいう新しいコンセプト導入してるのか・・・.思った以上にでかいのな・・・.
おー,さすがにptr_sequence_adapterは用意していただけましたか.自分が欲しいと思って作ったものはだいたいboostで作られていくなぁ.で,自分で作ったヤツはゴミ箱へ・・・(´・ω・`)ショボーン.Boostで用意されたならそれで大満足なんですけどね.なんかさびしいにゃ〜と.