Formal review of the Smart Container library
(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.


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


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の再整備が本質的な方向性であるべきだと漏れも思うんだけどなぁ・・・.