Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-04-21 11:33:33

"Pavel Chikulaev" <pavel.chikulaev_at_[hidden]> wrote in message
| 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

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

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
allow us to write a proxy reference for the iterators in pointer containers so
we can call
sort() etc. in the usual manner.


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