"Fredrik Blomqvist" <fredrik_blomqvist@home.se> wrote in message news:d43o6f$oia$1@sea.gmane.org...

...

I can't find any code or docs dealing with comparison in the current CVS. Weren't ptr_container supposed to have deep comparison semantics? Even if it had, you should make sure that your classes have properly implemented comparison operators. Yes of course, but they still wont be used unless the container fwds to

Pavel Chikulaev wrote: them.

Otherwise only base class's parts will be compared, and since such behaviour is undesirable and most users don't need any comparison operators or simply won't write them or will write them polymorphically incorrect, hmm, yes, I can see how it could be fairly error prone..

Thorsten, I guess, decided not to have comparison operators at all. My post was trigged by a note in the docs(?) suggesting they were supposed to be added. But now I can't seem to find a link to it again... (perhaps Thorsten updated some docs very recently?)

For proper comparison you should ensure that you comparing objects of the same dynamic type, then compare all base parts, the derived one. Because of this, it's just not possible to write comparison operators for ptr_container with every type you put in it. Couldn't the lib assume/trust them to be polymorphic in that case? (and as correct as such implementation allows)

BTW, you can always write our own comparison operators for ptr_containers of your classes if you really need them. Yes. Perhaps they could simply be put in a separate header to be pulled in if needed?

Regards // Fredrik Blomqvist

"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:d48a18$pmi$1@sea.gmane.org... | "Fredrik Blomqvist" <fredrik_blomqvist@home.se> wrote in message || > Thorsten, I guess, decided not to have comparison operators at all. | | no. | || My post was trigged by a note in the docs(?) suggesting they were supposed || to be added. But now I can't seem to find a link to it again... || (perhaps Thorsten updated some docs very recently?) | | well, yeah, the cvs docs are almost up to date. | | anyway, the comparison operators are implemented as members using | boost.operators. | | I'll opdate the test to test these operators. Actually there was already a test in ptr_vector.cpp: assign::push_back( vec )( new int(2) ) ( new int(4) ) ( new int(6) ) ( new int(8) ); ptr_vector<int> vec2; assign::push_back( vec2 ) ( new int(1) ) ( new int(3) ) ( new int(5) ) ( new int(7) ); BOOST_CHECK( vec < vec2 ); BOOST_CHECK( vec != vec2 ); BOOST_CHECK( !(vec == vec2 ) ); BOOST_CHECK( vec2 > vec ); BOOST_CHECK( vec <= vec2 ); BOOST_CHECK( vec2 >= vec ); -Thorsten

...

Thorsten, I guess, decided not to have comparison operators at all. no. Maybe you should at least warn users in docs about undesired effects of using

"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:d48a18$pmi$1@sea.gmane.org... them? -- Pavel Chikulaev

"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:d48jno$u6v$1@sea.gmane.org...

what effects are you talking about? They are implemented by delegating to to objects operator X. And there's the real problem - user is most likely to write comparison operators badly.

-- Pavel Chikulaev

From: "Fredrik Blomqvist" <fredrik_blomqvist@home.se>

Pavel Chikulaev wrote:

...

"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:d48jno$u6v$1@sea.gmane.org...

...

what effects are you talking about? They are implemented by delegating to to objects operator X. And there's the real problem - user is most likely to write comparison operators badly. I don't think that's a compelling argument, _anything_ can surely be written badly resulting in other components building on it to fail? "Trust the programmer" as the long-time C++ motto says.

I prefer, "Trust, but verify." -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;