🚀 go-pugleaf

In article <950@edg1.UUCP> jsa@edg1.UUCP (J. Stephen Adamczyk) writes:
>The ARM (5.1.7) says that the value of an assignment operator is
>an lvalue.  That's different than ANSI C (3.3.16).  There must
>be a reason for the difference; can anyone enlighten me?

I surmise, without really knowing, that people want to write things
like `(a = b).foo', for which it is required that the assignment
return an lvalue.

>Also (different topic) -- is the example right at the end of
>12.4 of the ARM, i.e.,
>
>  int *p;
>  p->int::~int();
>
>really thought to be legal?  Isn't the name to the left of "::"
>required to be a class-name?

Hm!  You seem to have found an inconsistency in the ARM.  The
definitions on p. 24, and especially the comment near the top of p.
25:

  We refer to classes (including structures and unions) as
  *user-defined* types and other types as *built-in* types [emphasis
  in original].

seem to say quite clearly that `int' is not a class name, and the
description of a qualified name on p. 48 says pretty clearly that a
class name is required.  Seems like the latter needs to be fixed.

The purpose of allowing code such as this example, of course, is to
allow templates to be expanded with both built-in and user-defined
types.

-- Scott
Gyro@Reasoning.COM

In article <1991Apr24.184018.23427@kestrel.edu> gyro@kestrel.edu (Scott Layson Burson) writes:
>In article <950@edg1.UUCP> jsa@edg1.UUCP (J. Stephen Adamczyk) writes:
>>The ARM (5.1.7) says that the value of an assignment operator is
>>an lvalue.  That's different than ANSI C (3.3.16).  There must
>>be a reason for the difference; can anyone enlighten me?
>
>I surmise, without really knowing, that people want to write things
>like `(a = b).foo', for which it is required that the assignment
>return an lvalue.

No. Consider the following program:

struct X { int i; };
X f() { X x; return x; }
main()
{
	int i = f().i;	// OK
	X x;
	f() = x;	// !OK
}

f() does NOT return an lvalue, the last line in the program is therefore
illegal. However, f().i is of course allowed, and so would be (a = b).foo, 
even if = didn't return an lvalue.

Martin hitz@csi.uottawa.ca

Martin Hitz <hitz@sim5.csi.uottawa.ca> writes:
>struct X { int i; };
>X f() { X x; return x; }
>main()
>{
>	int i = f().i;	// OK
>	X x;
>	f() = x;	// !OK
>}
>
>f() does NOT return an lvalue

I would have thought that f() *does* return an lvalue, albeit in the
form of a temporary variable.  Note that the following *does* work:

	#include <iostream.h>

	struct X { int i; };
	X f() { X x; x.i=12; return x; }
	main()
	{
		X x;

		x.i = 23;

		X & xref = f();
		cout << "xref is " << xref.i << '\n';
		xref = x;
		cout << "x is " << x.i << ", while xref is now " << xref.i << '\n';
	}

The output from this is

	xref is 12
	x is 23, while xref is now 23

So it would seem that your [and my!] version of cfront is broken..

					Reid
--
Reid Ellis     1 Trefan Street Apt. E, Toronto ON, M5A 3A9
rae@utcs.toronto.edu        ||               rae@alias.com
CDA0610@applelink.apple.com ||      +1 416 362 9181 [work]

In article <1991Apr25.030006.5849@csi.uottawa.ca> hitz@sim5.csi.uottawa.ca (Martin Hitz) writes:
>In article <1991Apr24.184018.23427@kestrel.edu> gyro@kestrel.edu (Scott Layson Burson) writes:
>>In article <950@edg1.UUCP> jsa@edg1.UUCP (J. Stephen Adamczyk) writes:
>>>The ARM (5.1.7) says that the value of an assignment operator is
>>>an lvalue.  That's different than ANSI C (3.3.16).  There must
>>>be a reason for the difference; can anyone enlighten me?
>>
>>I surmise, without really knowing, that people want to write things
>>like `(a = b).foo', for which it is required that the assignment
>>return an lvalue.
>
>No. Consider the following program:
> [deleted]
>
>f() does NOT return an lvalue, the last line in the program is therefore
>illegal. However, f().i is of course allowed, and so would be (a = b).foo, 
>even if = didn't return an lvalue.

Oops, I meant to say `(a = b).foo()'.  As I read E&S, this would still
be legal if assignment returned an rvalue, but would mean something
different: where the current meaning is the same as `(a = b, a.foo())' ,
if assignment returned an rvalue, it would be more like

    T temp = (a = b);
    temp.foo();

However, I can't completely convince myself that this analysis is
correct, because while E&S (5.17, p. 79) says that the result of an
assignment is an lvalue, it neglects to say *which* lvalue it is.
This seems like a lacuna in the specification.

-- Scott
Gyro@Reasoning.COM