Primitive vs. non-primitive l-value

[richardclay09]

Given these structs and funcs:

struct X { X& operator++() { return *this; } };

X f1() { return X(); }

int f2() { return 666; }

Why does one of these work, but not the other (fun quiz - predict which
one won't):

X x = ++f1();
int x = ++f2();

 

[Victor Bazarov]

Given these structs and funcs:

struct X { X& operator++() { return *this; } };

X f1() { return X(); }

int f2() { return 666; }

Why does one of these work, but not the other (fun quiz - predict which
one won't):

X x = ++f1();
int x = ++f2();

f2 won't. Lemme check... Yep, Comeau agrees with me. In C++ there
are lvalues and rvalues. A temporary that is an instance of a class
is an lvalue and an int temporary is an rvalue. operator ++() requires
an lvalue, that's why f2 fails and f1 doesn't.

V

 

[Samee Zahur]

I didn't realize that qs like this are these common! Take a look at my
recent posts. It was left pretty much 'unanswered'

http://groups-beta.google.com/group...read/thread/532943e5798f58db/e3aa4aac4225190b

Samee

 

[Victor Bazarov]

I didn't realize that qs like this are these common! Take a look at my
recent posts. It was left pretty much 'unanswered'

http://groups-beta.google.com/group...read/thread/532943e5798f58db/e3aa4aac4225190b

What's "unanswered" there? Your regret that built-in types are
treated differently than user-defined ones WRT temporaries? And how
would you prefer it is "answered"? "Yes, dude, we feel your pain"?..

 

[Samee Zahur]

"Yes, dude, we feel your pain"?..

Very funny ... what I meant was that the discussion could have gone on
to explaining *why* things are the way they are ... and other things
.... let me drag out some of the stuffs from that thread since you ask:

non-const methods of temporaries can be called - yet built-in types
cannot be modified. Fine (don't know why, but fine for now). But *all*
temporaries when passed into functions as references must be passed as
const references! I don't get it, if temporaries can be mutated in
place, why can't a function receiving it as an arguement do the same?
Why can't a function accept it as a non-const reference so it can call
some mutating functions on it's own ... it can sometimes be a headace
in operator overloads!

Samee

 

[Victor Bazarov]

Very funny ... what I meant was that the discussion could have gone on
to explaining *why* things are the way they are ...

Post to comp.std.c++ for that. They own and dispense rationales behind
the Standand.

and other things
... let me drag out some of the stuffs from that thread since you ask:

non-const methods of temporaries can be called - yet built-in types
cannot be modified. Fine (don't know why, but fine for now).

"Why" is simple: built-in types are treated by the hardware differently.

But *all*
temporaries when passed into functions as references must be passed as
const references! I don't get it, if temporaries can be mutated in
place, why can't a function receiving it as an arguement do the same?

That has nothing to do with mutability. It has everything to do with
ensuring the _lifetime_ of the object.

Why can't a function accept it as a non-const reference so it can call
some mutating functions on it's own ... it can sometimes be a headace
in operator overloads!

It can. But it all can be understood learned, and the headache usually
goes away.

V

 

[Samee Zahur]

non-const methods of temporaries can be called - yet built-in types

"Why" is simple: built-in types are treated by the hardware

differently.

C++ standard does not care about hardware - it doesn't recognise the
existence of even a keyboard! The whole point about creating C++ was a
language that treats user-defined types as a "first-class citizen" - so
a discrepency like this seems a little
awkward and against it's own philosophies (if I understood them
correctly)

And yes, I do intend to post something like this in c.s.c++ (I've to
check if I have already

See ya

Samee

 

[Victor Bazarov]

differently.

C++ standard does not care about hardware - it doesn't recognise the
existence of even a keyboard!

This has no bearing on the problem at hand. Read 3.9.1/2. What is,
in your opinion, "the natural size suggested by the architecture of
the execution environment"? Has it no connection to the hardware?
Also, the representation of all values in C++ requires that internal
representation has the binary form. What is it if not "caring about
hardware"? If it didn't care, there would be no concept of "bit" in
the language. So, don't give me this "does not care" nonsense, please.

The whole point about creating C++ was a
language that treats user-defined types as a "first-class citizen" - so
a discrepency like this seems a little
awkward and against it's own philosophies (if I understood them
correctly)

Generally speaking, yes. However, there are particular differences
that cannot simply be discarded or ignored.

And yes, I do intend to post something like this in c.s.c++ (I've to
check if I have already

Good.