One more foolishness of the C++ Standard
in [Visual C]
|
Prev: Why is CArchive class not derived from Cobject class in MFC
Next: What happens when Win+E is pressed?
From: sasha on 21 Jan 2010 19:34 Duane Hebert wrote: > But if I have a ctor taking int, string and another taking string,int > how does it relate to the > == operator? This compares instances of an object that has already been > constructed. > I can have 27 ctors for a class and only one == operator. The STL algorithms may not use all of available constructors.
From: Ulrich Eckhardt on 22 Jan 2010 03:08 Vladimir Grigoriev wrote: > The problem is the same as with std::min and std::min_element. I do not > see any reasonable explanation why these restrictions were adopted. It > seems that this shrinks functionality of C++ without any serious reason. What is "this"? Further, you must know that the STL wasn't developed very far at the point where it was incorporated in the C++ standard. This explains at least a few areas that could be improved. > For example all that I have heard here relative to std::min is some > references to sort algorithms. However I do not see a relation > between std::min and sort algorithms.. I do, std::min returns the first element that a sequence would have after std::sort'ing it, simple as that. In that sense, it makes sense for std::min to require the same semantics of the predicate as std::sort. BTW: why did you quote all the following text while not even referring to it? It makes it hard to guess what you mean.... > Vladimir Grigoriev > > "Ulrich Eckhardt" <eckhardt(a)satorlaser.com> wrote in message > news:5acm27-40c.ln1(a)satorlaser.homedns.org... >> Vladimir Grigoriev wrote: >>> There is no a great sense to compare some size_t value with an object of >>> type Person. This comparison has no sense. It is a general situation >>> when converting some object of a class to an integral type has sense >>> while converting an integral type to an object has no sense. For this >>> purpose the explicit reywoard was introduced. The same is valid for >>> operators. i.e. sometimes a op b has sense while b op a has no sense. >> >> I'd say whether switching operands still has sense depends on the >> operator. >> For an equality comparison, I expect it to be fully commutative. >> Similarly for inequality, while e.g. greater behaves slightly different. >> >> Are you really implying that a==b makes sense when b==a doesn't? I >> already voiced my opinion on comparison of a person with an ID: "I >> wouldn't overload operator== for that." >> >> Uli >> >> -- >> C++ FAQ: http://parashift.com/c++-faq-lite >> >> Sator Laser GmbH >> Geschaftsfuhrer: Thorsten Focking, Amtsgericht Hamburg HR B62 932 Uli -- C++ FAQ: http://parashift.com/c++-faq-lite Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
From: Ulrich Eckhardt on 22 Jan 2010 03:11 Vladimir Grigoriev wrote: > There are situations when A is a subset of B and in this case you may > apply some relation or comparison operator showing that A is a subset of > B. However you may not state that B is a subset of A. So a reverse > relation is absent and consequently reverse operators also are absent. That is a violation of the principle of least surprise to overload operator= then. > For example you can define a Point class derived from std::pair. And your > Point class may have arithmetic operators. You may to add a std::pair > object to a Point object but your may not add a Point object to a std:pair > object. Why not? If a+b computes then b+a should, too. Curiosum btw: float a[42]; 0[a] = 3.1416f; Though I would personally say this goes too far. ;) > Otherwise std::pair class will have a feature which was not > supposed to be. The same situation can be with relation operators. I disagree. Uli -- C++ FAQ: http://parashift.com/c++-faq-lite Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
From: Martin B. on 22 Jan 2010 04:50 Vladimir Grigoriev wrote: (You know, some people consider it good practise to properly quote messages in a NG.) > There is no a great sense to compare some size_t value with an object of > type Person. This comparison has no sense. It is a general situation when > converting some object of a class to an integral type has sense while > converting an integral type to an object has no sense. For this purpose the > explicit reywoard was introduced. The same is valid for operators. i.e. > sometimes a op b has sense while b op a has no sense. > Well. If you have a type where (a special_equals b) does not imply (b special_equals a) then-do-not-define operator== ! This will utterly confuse the maintainer that has to add something to the code in March 2011 and will highly increase the likelihood of bugs. If I would be doing code reviews (which I don't) I would never accept code that messes in this way with op== (Likewise, I hate the people here who wrote these stupid assignment operators that do-not-copy-the-whole-object. It's horrible for maintenance!) !!Principle of least surprise!! My Opinion, Martin > Vladimir Grigoriev > > "Martin B." <0xCDCDCDCD(a)gmx.at> wrote in message > news:hj9r7v$9f9$1(a)news.eternal-september.org... >> Vladimir Grigoriev wrote: >>> Let consider an example. >>> >>> There is a class named Person. And it has a member size_t personalID and >>> an equality operator >>> >>> bool operator ==( const Person &lhs, size_t targetID ); >>> >>> However there is not a Person constructor with one argument equal to >>> size_t as a personal ID. >>> So there is the above equality operator and there is no a reverse >>> equality operator as >>> >>> bool operator ==( size_t targetID, const Personal &rhs ); // invalid >>> >> Could you explain this to me? What is the actual problem? >> >> This compiles just fine: >> class Foo { }; >> >> bool operator==(Foo const& lhs, size_t rhs) { >> return true; >> } >> >> bool operator==(size_t lhs, Foo const& rhs) { >> return true; >> } >> >> void f() { >> Foo o = Foo(); >> size_t i = size_t(); >> >> if( o == i) { >> // x >> } >> else if(i == o) { >> // y >> } >> else { >> // z >> } >> } >> >> >> >> cheers, >> Martin > >
From: Vladimir Grigoriev on 22 Jan 2010 07:19
I can not agree with your statement. In real world and in mathematics there are relations which are not symmetrically equivalent. Sometimes an equality operator means belonging. Vladimir Grigoriev "Martin B." <0xCDCDCDCD(a)gmx.at> wrote in message news:hjbsch$f3v$1(a)news.eternal-september.org... > Vladimir Grigoriev wrote: > > (You know, some people consider it good practise to properly quote > messages in a NG.) > >> There is no a great sense to compare some size_t value with an object of >> type Person. This comparison has no sense. It is a general situation when >> converting some object of a class to an integral type has sense while >> converting an integral type to an object has no sense. For this purpose >> the explicit reywoard was introduced. The same is valid for operators. >> i.e. sometimes a op b has sense while b op a has no sense. >> > > Well. > If you have a type where (a special_equals b) does not imply (b > special_equals a) then-do-not-define operator== ! This will utterly > confuse the maintainer that has to add something to the code in March 2011 > and will highly increase the likelihood of bugs. > If I would be doing code reviews (which I don't) I would never accept code > that messes in this way with op== > (Likewise, I hate the people here who wrote these stupid assignment > operators that do-not-copy-the-whole-object. It's horrible for > maintenance!) > > !!Principle of least surprise!! > > My Opinion, > Martin > >> Vladimir Grigoriev >> >> "Martin B." <0xCDCDCDCD(a)gmx.at> wrote in message >> news:hj9r7v$9f9$1(a)news.eternal-september.org... >>> Vladimir Grigoriev wrote: >>>> Let consider an example. >>>> >>>> There is a class named Person. And it has a member size_t personalID >>>> and an equality operator >>>> >>>> bool operator ==( const Person &lhs, size_t targetID ); >>>> >>>> However there is not a Person constructor with one argument equal to >>>> size_t as a personal ID. >>>> So there is the above equality operator and there is no a reverse >>>> equality operator as >>>> >>>> bool operator ==( size_t targetID, const Personal &rhs ); // invalid >>>> >>> Could you explain this to me? What is the actual problem? >>> >>> This compiles just fine: >>> class Foo { }; >>> >>> bool operator==(Foo const& lhs, size_t rhs) { >>> return true; >>> } >>> >>> bool operator==(size_t lhs, Foo const& rhs) { >>> return true; >>> } >>> >>> void f() { >>> Foo o = Foo(); >>> size_t i = size_t(); >>> >>> if( o == i) { >>> // x >>> } >>> else if(i == o) { >>> // y >>> } >>> else { >>> // z >>> } >>> } >>> >>> >>> >>> cheers, >>> Martin >> |