Hi, as a consequence of my daily work in COM design, it revealed, that most often there are only views into existing containers required, so copies can be delayed, until container invariants are viloated - elements are already shared, as they reference pointers with embedded reference counts. Thus, the design fulfills the following objectives : + Every existing container can be adopted to be a shareable container. Shareable means, concurrent read and write access to elements. Container invariant methods, such like insert for sorted associative containers, trigger a copy of the container. + Iterators are managed. This guarantees valid iterators, even if the underlying container is copied, because of a container invariant modifying operation. + The existing concepts for containers are mapped to support shared containers. This avoids any redundant code and provides maximum flexibility in combining concepts via base class chaining. + Every shared container behaves simply like its stl or boost counterpart (except unsorted, because of a current unsolved issue regarding the iterators in buckets, requiring a second layer of managed iterators - imho inefficient), so that usage is as simple as with original containers. A brief example using boost::shared; set<int> x, y = x; // y is attached to the same container as x, no copy x.insert(3); // y gets detached from x, because set invariant (sort order) is modified list<int> x; x.push_back(3); list<int> y = x; y.front() = 8; // also modifies the value in x list<int>::const_iterator cit(x.begin()); // attach iterator to container shared by x and y y.pop_back(); // detaches y from container shared with x (container invariant) std::cout << *cit << std::endl; // output : 8 (iterator still valid) Is there any interest for boost, to support such a library or is the number of use cases to small to introduce something like that ? Thx, ILo.