"Pavel Chikulaev" <pavel.chikulaev@gmail.com> wrote in message news:d48duh$7oj$1@sea.gmane.org... | 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. base::operator==(...) should delegate to a protected or public function. | Second if you provide comparasion operators (with concept checking or not) | it's quite strange that ptr_containers aren't CopyConstructible and Assignable. not at all. copying by cloning is vastly different from copying; so different that those two things should not be interchangeable. | P.S. What do you think about my post | Proposal: is_swapable, is_nothrow_swapable, nothrow_swap,swap dated | 04/12? I looked briefly at it; I recall to think that it was not worth the effort. I talked with Howard Hinnant about the issue and I think we concluded that the introduction of move-semantics and changes to the standard algorithms would allow us to write a proxy reference for the iterators in pointer containers so we can call sort() etc. in the usual manner. -Thorsten