Re: Temporary objects, l-values.

Thanks for the quick reply!

All right, so... now I have lots of nitpicky questions...

"Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message
news:fpe7i8$trk$1@aioe.org...


Ok. Now if you have this:

{
  SomeThing x;
  function1(x);
}

There, x itself is not a "temporary object", right, because you
explicitly
declare it, then use it in another statement -- even though it has a
very
short life. But if you "shorten" that to this:

{
  function1(SomeThing());
}

Then that SomeThing you pass to function1 *is* a "temporary object".
The
line is when you ... define the object explicitly in a separate
statement,
so it's lifetime is longer than just the expression it was defined in?
Do I
have that right?


Thanks for the section reference. I'll read through it tomorrow, it
should
clear up my confusion.


I'm sorry, I don't understand. I'm having a hard time thinking about
this.
When I see people describe what an l-value is, it is usually described
as
"something that can appear on the left side of an = sign". I take that
to
mean "something that can be set equal to something else".

So what you are saying is: Because the assignment operator is a
member
function for class types, a class type does not necessarily have to be
an
"l-value" to appear on the left side of an = sign, because it's just
like
calling any other member function. Since I can do
"SomeThing().SomeMemberFunction();", I can do "SomeThing().operator =
(...);" as well, even though it's not an l-value. Right?

The reason that I thought SomeThing() was an l-value is because it
could
appear on the "left side of an = sign". But, I guess the definition
is
deeper than that. So... what does it take for a class type value to be
an
l-value then? If the fact that the = operator is just another member
function like any other means that "SomeThing() = ...;" does not imply
that
SomeThing() is necessarily an l-value, then it seems like the "=" sign
and
the "l-value-ness" of a class type are completely unrelated concepts?
In
other words, if "SomeThing()" can appear on the left side of an =
sign, but
it is not an l-value, then what *is* an l-value (since being able to
be to
the left of an = is not the only requirement)?

Is it more accurate to say an l-value is "something that can be set
equal to
something else", and not worry about the "=" at all... so it's more
about
the meaning of the statement? What I mean is, if you have a type and
you
implement an = operator for it that does something else that isn't
assignment, then in that case "=" has nothing to do with l-values.
Similarily, if you have a member function, say, "Assign()" that does
do
assignment, then an l-value of that type is a value where it's
meaningful to
call "Assign()" on, even though the assignment operator itself is not
involved?

I am not disagreeing at all -- I'm just trying to wrap my head around
what
you typed, because I'm pretty easily confused.


I'm sorry, "2 = 3" was a really bad example that I used to try to
describe
something that I didn't know the word for. What I meant was something
like
"in most situations, it's a silly thing to do" (for lack of a better
phrase). Sort of like... assuming the = operator for a type has no
side
effects, then doing something like "A() = whatever;" doesn't have any
effect
on your program. If you removed it, everything would still be the
same.
That's kind of more what I meant. It was a very bad example.


It does not compile with GCC... I must have confused myself with
different
test cases. Argh. Thanks for double-checking that.


I did not think temporaries were const. I think I went the extreme in
the
other direction, trying to assign temporaries to other things. My
logic was
all screwed up. This is what I had thought:

1) L-values are things that appear on the left side of = operators.
2) "(Y(x))" can appear on the left side of = operator.
3) Temporaries are not l-values. Temporaries can not be assigned to
other
things.
4) Therefore, Y(x) is not a "temporary".
5) Therefore, Y(x) can bind to a non-const reference.

But the flaw in that "proof" (of sorts) is that pretty much every
point is
wrong :( . Because like you said above, the = operator is just
another
non-const member function for class types, nothing special about it.
And
temporaries are not necessarily const.


If you can call the assignment operator on a temporary, why are you
not
allowed to bind temporaries to non-const reference parameters? I mean,
code
like this *seems* entirely reasonable to me:

void function (A &a) {
  // do some stuff to a here
}

void function2 (void) {
  function(A());
}

Why is that illegal? You create a new A(), pass a reference to it to
function (so it's not copied when you call function(), it's created
before
the actual call is made), it's valid inside function(), you can do
stuff to
it, function() returns, statement ends, A() is destroyed. It doesn't
seem
dangerous, unpredictable, indeterminant, or anything. Do you know why
you
aren't allowed to do that, then (mostly for my own curiosity, I don't
actually have a program that I "need" to do something like that in)?

And since temporaries are not necessarily const, why can they (even
the
non-const ones) only be bound to const references?


*That* is what I was trying to say with the stupid "2=3" example. "No
point". Duh.


It's an off-topic discussion on a Borland newsgroup about exactly
this
topic. Whether or not you can bind A() to a non-const reference
parameter.
The source of the confusion is two things:

1) I'm not familiar enough with the standard to know what the real,
correct
behavior is, and
2) The Borland compiler *does*, in fact, accept the above code (with
"function(A());").

There was some confusion about which was correct so I asked here to
get a
real answer. The Borland compiler is wrong, of course. It's strange
because
with the [broken] Borland compiler, the following is accepted, like I
said:

struct X { };

struct Y {
  Y (const X &) { }
};

void function (Y &) { }

void function2 (void) {
  X x;
  function(Y(x));
  function((Y)x);
}

But this is not (complaining about binding l-values to non-const
references):

struct Y {
};

struct X {
  operator Y () { return Y(); }
};

void function (Y &) { }

void function2 (void) {
  X x;
  function(Y(x));
  function((Y)x);
}

The difference being that in the first example the conversion uses
Y's
constructor, but in the second the conversion uses X's cast operator.
It's
totally weird.

Thanks again for your time!
Jason