this is not a review hi all congratulations for you, chad, on that you got so far i hope all your effort will pay back you a good value i wanted to say a word on the copy-on-write thing as someone wisely noted on this list cow is in no way worse than plain copying in general when you make a copy you allocate new storage for the newly created copy and the allocation procedure, in general, locks a mutex in order not to corrupt the heap this is much more expensive even than atomic reference counting this only statement convinces me personally to use cow in newly created pieces of software moreover cow enables the size of the object on the stack (or in an array) ==sizeof(void*) then allocation of an array of such objects saves the heap and e.g. virtually any sorting procedure of an array with all its possible copies and moves becomes relatively cheap also it's not forbidden to implement move semantics along with cow (which appears to be trivial -- just swap the pointers) and i think that the struct storage { int_t ref_count; //other instance data value_type array[1]; }; idiom *should* be used (by default) for the cow internal implementation (by default the compiler cares about alignment of 'storage' members for you so you don't even get into it) in the end i have a question to chad: for what reason integer_t inherits its implementation *virtualy* ? you know that virtual inheritance involves (possibly unneeded) overhead -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out p.p.s. i'm the person who suggested to add algorithmic complexity estimates to the docs so blame me