4/30 Quick C++ question. In Meyer's More Effective C++, Item 22, he has
a snippet of code like this:
template<class T>
const T operator+(const T& lhs, const T& rhs)
{
return T(lhs) += rhs;
}
My question is, why is it legal to do 'T(lhs) += rhs;'? T(lhs) yields
a temporary, which is AFAIK, an rvalue, so since operator+= is not a
const member function, the compiler shouldn't allow that line. My
reading of the C++ standard seems to support my line of thought. But
OTOH, g++ 3.4.0 happily accepts code similar to the above. So am I
missing something here? Thanks.
\_ T(lhs) is calling the copy constructor, which returns an object;
I don't think it counts as a temporary. Not sure though.
\_ No, T(lhs) is the functional cast expression, which may call a
constructor (but not the copy constructor). Section 5.2.3/1 of
the standard says that T(lhs) (that is, a type followed by parens
and a single argument) is equivalent to (T)lhs. 5.4/1 then says
that (T)lhs for a REFERENCE type is an lvalue, but for a
non-reference type it's an rvalue. -emarkp
\_ I agree with what you say, except for the part where you say
a copy constructor can't be called. That's illogical, and I
don't see where the standard says anything about that anyway.
\_ Well, that's the only part that isn't clearly in the
standard, so I'm glad you agree with the rest. :) Anyway,
the standard says that: T(x) is equivalent to (T)x, which
any compiler will turn into a noop if the type of x is T.
I guess one exception for this would be if the type of x is
T const. In which case I guess it would call the copy
constructor if T is not a reference type. T *is* a
reference type in the example though. -emarkp
\_ Oops, my bad. Yeah, this would call the copy
constructor (what was I thinking?) because of course lhs
can't be modified, but since lhs is a reference type the
copied object is an lvalue. I'm sure this is one of the
screwy type rules that was made precisely for operator
overloading. Sorry for the screwup. -emarkp
\_ Hmm, I don't think so. lhs may be of reference
type, but T(lhs), which is the same as (T)lhs, is of
type T, which is not necessarily a ref type. -op
\_ Okay, section 3.10/10: An lvalue for an object is
necessary in order to modify the object except
that an rvalue of class type can also be used to
modify its referent under certain circumstances.
[Example: a member function called for an object
(9.3) can modify the object.] So it *is* being
copied, and it *is* an rvalue, but non-const
member functions can modify an rvalue of class
type. -emarkp
\_ That's nasty, but thanks! -op
\_ Ob: And this is why C++ sucks.
\_ I agree it is often way too complex, but it has its moments. -op
\_ Ironically, the reason this is so complex is so that it will work
like you expect, or in a way that a compiler can optimize well.
\_ Disagree. At a certain point of complexity it's no longer
economical to expect anything. All of this would be irrelevant
with T.add(lhs, rhs).
\_ Are you arguing against overloaded operators? In your
expression, where does the sum go?
\_ It's returned as an instance of of T. I'm not being a
smartass here, I'm just wondering about cases where
operator overloading saves anything more than a few
characters of function name. What's the real win?
\_ Operator overloading is essential to having
user-defined types that don't feel like second-class
citizens. "Smart pointers" would be syntactically
ugly and cumbersome to use if you couldn't overload
pointer-ish operations, for example. I'm sure there
are lots more examples when you start using c++ as
more than just "a better C".
\_ To whoever asked why ocaml syntax is so warty
-- in part because ocaml has no operator
overloading. I sometimes wish it was there,
but I am not holding my breath. The ocaml way
\_ Perl.
is that the operator can only be the same if
the underlying algorithm is the same (so for
instance they have +. for floats and + for ints,
but < for both floats and ints). So they have
'polymorphism' instead of 'overloading'.
-- ilyas |
http://csua.com/feed/