Thorsten, So we're going to have comparison operators in ptr_container, despite possible polymorphism-related errors. Let me show you some problems with them: e.g. class Base{}; class Derived : public Base {}; bool operator == (const Base &, const Base &); //Handles correctly Base and Derived //then user add class DerivedAgain : public Derived {}; and forget update operator == then all operations == on DerivedAgain objects will use Derived operator ==. And AFAIK user just can't automate reminder about forgotten operator == without registering DerivedAgain somewhere, so all DerivedAgain wrong comparasions will get green light. And I do believe it's undesirable behavior. My vision of the problem: provide all comparison operators, but with compile-time checking that ensures user defined specialization of some traits class: template<> struct has_proper_polymorphic_equal_operator<Base> { enum { value = true; } }; while by default has_proper_polymorphic_equal_operator<T>::value returns false. Second if you provide comparasion operators (with concept checking or not) it's quite strange that ptr_containers aren't CopyConstructible and Assignable. Using the same technique we can provide them: template<> struct is_clonable<Base> { enum { value = true }; }; template<> struct clone<Base> { Base * do_clone(Base * pb) { return pb->CloneMe(pb); //or any other name } }; And I believe that operator = is much needed than comparison operators in real-life applications. So what do you think? P.S. What do you think about my post Proposal: is_swapable, is_nothrow_swapable, nothrow_swap,swap dated 04/12? -- Pavel Chikulaev