Boost logo

Boost :

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


So we're going to have comparison operators in ptr_container, despite
possible polymorphism-related errors.
Let me show you some problems with them:
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

My vision of the problem:
provide all comparison operators, but with compile-time checking that ensures
user defined specialization of some traits class:

struct has_proper_polymorphic_equal_operator<Base>
     enum { value = true; }

while by default has_proper_polymorphic_equal_operator<T>::value returns

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:

struct is_clonable<Base>
    enum { value = true };

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

Pavel Chikulaev 

Boost list run by bdawes at, gregod at, cpdaniel at, john at