[boost] [ptr_container] more operators?

From: Pavel Chikulaev (pavel.chikulaev_at_[hidden])
Date: 2005-04-21 09:42:40

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