template operator== not working
in [Visual C]
|
From: Ben Voigt [C++ MVP] on 8 May 2008 12:51 >> You might not see that example as typed but if( a * b = c) ... does >> occure because of typing mistakes. The compiler will catch this. > > And why would you want to prevent that? Because the side-effect of the assignment operator is to change a temporary that is immediately thrown away, obviously not intended. The programmer meant to use the comparison operator == instead.
From: 3DCoderGuy on 8 May 2008 12:54 "Alf P. Steinbach" <alfps(a)start.no> wrote in message news:TZ6dnYvPIYCAtb7VnZ2dnUVZ_sednZ2d(a)comnet... ....snip... >> >> Thanks Alexander for your reply. >> The use of const on the return comes from Scott Meyers' Effective C++ >> Third Edition Item 3 >> "const Rational operator*(const Rational& lhs, const Rational& rhs); >> Many programmers squint when they first see this. > > And rightly. > > With the current language definition it prevents optimizations like > Andrei's Mojo move semantics. > > C++0x is another matter. > >> Why should the result of operator* be a const object? > > Ideally it shouldn't, but there is no great harm, just a loss of possible > optimization. > >> Because if it weren't, clents would be able to commit atrocities like >> this: >> Rational a, b, c; >> ... >> (a * b) = c; // invoke operator= on the result of a*b! >> ..." >> >> You might not see that example as typed but if( a * b = c) ... does >> occure because of typing mistakes. The compiler will catch this. > > And why would you want to prevent that? ??? sorry, why wouldn't I want to prevent that? This int a = 2, b = 3, c = 4; if (a * b = c); fails to compile as I would expect. Why would I want my class to allow such a syntax? > >> Now this might not apply to the operator== but it is a practice I've >> picked up and just haven't changed. > > It would be a good idea to change it (see above). > Hit me with the 2x4, doesn't the example I give above prove why I shouldn't change. Mark
From: Alf P. Steinbach on 8 May 2008 13:25 * Ben Voigt [C++ MVP]: >>> You might not see that example as typed but if( a * b = c) ... does >>> occure because of typing mistakes. The compiler will catch this. >> And why would you want to prevent that? > > Because the side-effect of the assignment operator is to change a temporary > that is immediately thrown away, obviously not intended. > > The programmer meant to use the comparison operator == instead. Did she? Anyway, the techniques for dealing with inadvertent-assignment-in-condition for built-in types (namely high warning level for compilation, writing constants on left side, code inspection, systematic testing, etc.) apply here also. Fixing that possible problem for e.g. class Rational amounts to nothing compared to the rest of code, and as mentioned it does have a cost, so, pain but no gain. Cheers, - Alf -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
From: Alf P. Steinbach on 8 May 2008 13:33 * 3DCoderGuy: > "Alf P. Steinbach" <alfps(a)start.no> wrote in message > news:TZ6dnYvPIYCAtb7VnZ2dnUVZ_sednZ2d(a)comnet... > ...snip... >>> Thanks Alexander for your reply. >>> The use of const on the return comes from Scott Meyers' Effective C++ >>> Third Edition Item 3 >>> "const Rational operator*(const Rational& lhs, const Rational& rhs); >>> Many programmers squint when they first see this. >> And rightly. >> >> With the current language definition it prevents optimizations like >> Andrei's Mojo move semantics. >> >> C++0x is another matter. >> >>> Why should the result of operator* be a const object? >> Ideally it shouldn't, but there is no great harm, just a loss of possible >> optimization. >> >>> Because if it weren't, clents would be able to commit atrocities like >>> this: >>> Rational a, b, c; >>> ... >>> (a * b) = c; // invoke operator= on the result of a*b! >>> ..." >>> >>> You might not see that example as typed but if( a * b = c) ... does >>> occure because of typing mistakes. The compiler will catch this. >> And why would you want to prevent that? > ??? sorry, why wouldn't I want to prevent that? This > int a = 2, b = 3, c = 4; > if (a * b = c); > fails to compile as I would expect. > Why would I want my class to allow such a syntax? > >>> Now this might not apply to the operator== but it is a practice I've >>> picked up and just haven't changed. >> It would be a good idea to change it (see above). >> > Hit me with the 2x4, I already did but you didn't notice. :-) Sorry, I couldn't resist. :-) But anyways, take a look at e.g. the section titled "Optimizing Returning Values from Functions" at <url: http://www.ddj.com/database/184403855>, which is Andrei Alexandrescu's old article on "Move Constructors" (the Mojo framework). > doesn't the example I give above prove why I shouldn't change. Nope, it it only shows there is at least one valid reason for const result, when disregarding the negative effects of doing this. Cheers, & hth., - Alf -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
From: 3DCoderGuy on 8 May 2008 14:08
"Alf P. Steinbach" <alfps(a)start.no> wrote in message news:iradnWX7PrP8pL7VnZ2dnUVZ_tuonZ2d(a)comnet... >* 3DCoderGuy: >> "Alf P. Steinbach" <alfps(a)start.no> wrote in message >> news:TZ6dnYvPIYCAtb7VnZ2dnUVZ_sednZ2d(a)comnet... >> ...snip... >>>> Thanks Alexander for your reply. >>>> The use of const on the return comes from Scott Meyers' Effective C++ >>>> Third Edition Item 3 >>>> "const Rational operator*(const Rational& lhs, const Rational& rhs); >>>> Many programmers squint when they first see this. >>> And rightly. >>> >>> With the current language definition it prevents optimizations like >>> Andrei's Mojo move semantics. >>> >>> C++0x is another matter. >>> >>>> Why should the result of operator* be a const object? >>> Ideally it shouldn't, but there is no great harm, just a loss of >>> possible optimization. >>> >>>> Because if it weren't, clents would be able to commit atrocities like >>>> this: >>>> Rational a, b, c; >>>> ... >>>> (a * b) = c; // invoke operator= on the result of a*b! >>>> ..." >>>> >>>> You might not see that example as typed but if( a * b = c) ... does >>>> occure because of typing mistakes. The compiler will catch this. >>> And why would you want to prevent that? >> ??? sorry, why wouldn't I want to prevent that? This >> int a = 2, b = 3, c = 4; >> if (a * b = c); >> fails to compile as I would expect. >> Why would I want my class to allow such a syntax? >> >>>> Now this might not apply to the operator== but it is a practice I've >>>> picked up and just haven't changed. >>> It would be a good idea to change it (see above). >>> >> Hit me with the 2x4, > > I already did but you didn't notice. :-) Sorry, I couldn't resist. :-) > But anyways, take a look at e.g. the section titled "Optimizing Returning > Values from Functions" at <url: http://www.ddj.com/database/184403855>, > which is Andrei Alexandrescu's old article on "Move Constructors" (the > Mojo framework). > > > >> doesn't the example I give above prove why I shouldn't change. > > Nope, it it only shows there is at least one valid reason for const > result, when disregarding the negative effects of doing this. > > > Cheers, & hth., > > - Alf > > -- > A: Because it messes up the order in which people normally read text. > Q: Why is it such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? When you are clubing a guy who is down you could at least say Your Welcome. Thanks for the link. I'll have to read it another 6 times and see how I can add some Mojo to my code. Mark |