If you are using c++0x features the vector will try to move the object instead of copying. So in that case you can to implement move constructor and move assignment operator instead. If you don't need shared ownership you can use std::unique_ptr instead of shared_ptr.

Windows handles are not suitable for STL semantics.

You save a handful of cycles by reserving a vector then waste *trillions* needed to make each copy. Life cycle as required by std::vector is incompatible with heavy hardware resource allocation performed by each of calls above.

WinAPI resources are intended for kernel and OS. You don't just copy or create them just to be fancy. If a resource is created it will exist precisely for as long as it's needed. If for some reason it needs to be duplicated, then and only then it is, but in order to have two copies, not to make an overcomplicated move or swap. Never just for the sake of it to constrain to some foreign API.


Even more, critical sections or other synchronization primitives are incompatible with rule of three, since they cannot be properly implemented inside a destructor, meaning it can fail. Even though such constructs are often exposed using RAII, the semantics they represent cannot be properly implemented to comply with requirements of C++ object life cycle. They are, by definition, non-copyable.

1) remove all threading related constructs - synchronization is performed elsewhere (that means, classes like this cannot own a member synchronization primitive unless they are non-copyable, meaning they cannot be put into containers)
2) anything that allocates hardware or OS resources needs to be heap allocated and passed around via pointer, since its life-cycle does not match that of C++ scopes and auto-allocation

Hi Antheus.

Thanks for those points. Guess I've got a bit of a redesign to do then.

Many thanks.