gyro@kestrel.edu (Scott Layson Burson) (04/25/91)
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
hitz@sim5.csi.uottawa.ca (Martin Hitz) (04/25/91)
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
rae@alias.com (Reid Ellis) (04/27/91)
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]
gyro@kestrel.edu (Scott Layson Burson) (04/28/91)
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