Details on why DynObj needs a tweak to use in STL

STL containers use value-based semantics. This requires that the container element by copy-constructible and assignable, which tends to be incompatible with strict ownership of pointers. For instance, boost::scoped_ptr and std::auto_ptr provide strict ownership but do not work in STL containers, the former because it is not copyable, the latter because it uses implicit move-on-copy.

Like those two, DynObj prevents copy and assignment since they don't "fit" with the role of the class. The technique used by NoPtr is to allow DynObj a "controlled" form of copy and assignment within an STL container. This is allowed only when specifying DynObj<TT>::InValueContainer as the element type for DynObj when it will be used inside a value-based container. It is controlled in the sense that it is limited to the uses, by the STL containers themselves, that really require it, such as insertion into the container, and re-ordering of the container.

You may think that, DynObj<TT>::InValueContainer being a version of DynObj<TT> that allows copy and assignment, it is in essence shared ownership. However, DynObj<TT>::InValueContainer does NOT provide shared ownership. Remember that DynObj<TT>::InValueContainer is, from your point of view, identical to DynObj<TT>. The ::InValueContainer is necessary only because C++ does not currently provide any method of doing this without user (i.e. your) intervention. Any attempt, intended or not, to use the item inside a container of DynObj as a shared ownership smart reference will several assertions to fail at run-time.

---