Re: Friend operators don't work where class member operators do.
cesar tejeda wrote:
Historically (some twenty years ago), C++ did allow binding a
temporary to a non-const reference (and many compilers still
allow it today, as a non-conformant extension). It was found,
however, to be somewhat error prone, in cases like e.g.:
void
incr( int& i )
{
++ i ; // Obviously something more complex in real
// code.
}
void
f()
{
unsigned x = 0 ;
incr( x ) ;
}
In this case, the temporary is the result of an implicit
conversion, and the author is very surprised that the call to
incr doesn't modify x.
So I infer that for making a unsigned to int conversion, C++
creates a new temporary variable and copies the bits
C++ creates a new variable. Whether it just copies the bits or
not is implementation defined---all that is guaranteed is that
if the original type contained a value that is representable in
the target type, the target type will have that value. (Since
it is also guaranteed that signed integers use the same
representation as unsigned integers for non-negative values,
this means that you can count on getting the same bits for
values which fit.)
instead of the classical C
behaviour that is doing nothing and understanding the bits of x as bits
representing integers.
There is no difference between C and C++ here. The result of a
conversion is an rvalue, i.e. a temporary. Any apparent
difference is due to the fact that you generally cannot tell in
C; you can't take the address of the rvalue, and of course, you
can't bind it to a reference.
The most recent C standard (C99) is even more explicit, and says
that if the original value doesn't fit in the target type, you
can get an implementation defined signal. (There was some
ambiguity in the orginal C90 standard, and in the C++ standard,
which is almost a word for word copy in the relevant place, in
that it said that "the results are implementation defined".
Some people claimed that this meant that there must be results,
that a signal or a trap was not permitted, so the C committee
made it explicit that a signal (but not a trap) was permitted.)
Am I right?
Not really.
A conversion to other than a reference always results in an
rvalue, i.e. a temporary. In C++ and in C, and in C, going back
to well before the C standard. (In pre-standard C, the issue
was a bit ambiguous. K&R implied something along these lines,
but didn't say so explicitly, and the orginal C compiler did
accept conversions as lvalues. Other early C compilers, based
on the wording in K&R, didn't.)
With that behaviour it seems to me
that C++ code would take more time to execute if I have conversions of
that kind in my code.
I don't see where it could make the slightest difference.
On the other side, wouldn't it be better not to create temporaries for
the conversion and allow the code you wrote above to be correct and
execute giving correct results?
How could it? You can't manipulate one type as if it were
another.
I used int and unsigned more or less arbitrarily. It could
almost be made to work in such cases, provided the actual values
remained in the range of both types. The same example can occur
with int and short, int and double, etc. And there's no way of
making that work.
Otherwise, you should modify "f" function like this:
f()
{
unsigned x = 0 ;
int y=x;
incr( y ) ;
x=y;
}
Exactly. And since that's the only way that can actually be
made to work, that's why it's an error to attempt to do anything
else. (Today, of course, you'd make incr a template, and the
problem is solved:-).)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]