www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - * bogus codegen with static opAssign() usage *

reply kris <foo bar.com> writes:
Using static opAssign() apparently has some codegen issues. The 
following snippets are two variations of the same code; the first one is 
correct while the second is broken. Only flag enabled is -g. First, the 
operational version, which invokes this.opAssign() explicitly:

; FileProxy parent = this.opAssign(this.parent());
mov	EAX,-010h[EBP]
call	near ptr _D5tango2io8FilePath8FilePath6parentMFZAa
push	EDX
push	EAX
call	near ptr 
_D5tango2io9FileProxy9FileProxy8opAssignFAaZC5tango2io9FileProxy9FileProxy
mov	-0Ch[EBP],EAX

; char[] name = parent.name;
call	near ptr _D5tango2io8FilePath8FilePath4nameMFZAa
mov	-8[EBP],EAX
mov	-4[EBP],EDX


And now the busted version using opAssign() implicitly:


; FileProxy parent = this.parent();
mov	EAX,-010h[EBP]
call	near ptr _D5tango2io8FilePath8FilePath6parentMFZAa
push	EDX
push	EAX
call	near ptr 
_D5tango2io9FileProxy9FileProxy8opAssignFAaZC5tango2io9FileProxy9FileProxy
 doh! where did the return value go? <<<
; char[] name = parent.name; mov EAX,-0Ch[EBP] call near ptr _D5tango2io8FilePath8FilePath4nameMFZAa mov -8[EBP],EAX mov -4[EBP],EDX It's pretty clear that the broken version is discarding the result of the implicit opAssign() call; the assignment is simply being dropped. I'm copying this here since it'll just get lost amongst the weeds in d.bugs. I don't have a small test case: took hours to track this down as it was, and it's deep in the Tango library.
Feb 18 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
	a = b;

is replaced with:

	a.opAssign(b);

not:

	a = a.opAssign(b);

The return value of opAssign comes in to play with:

	c = a = b;

which is rewritten as:

	c = a.opAssign(b);
Feb 18 2007
next sibling parent Gregor Richards <Richards codu.org> writes:
Walter Bright wrote:
     a = b;
 
 is replaced with:
 
     a.opAssign(b);
 
 not:
 
     a = a.opAssign(b);
 
 The return value of opAssign comes in to play with:
 
     c = a = b;
 
 which is rewritten as:
 
     c = a.opAssign(b);
This makes quite a bit of sense, actually. It's consistent. But it begs the question: Is there a way to do what is desired here? That is: SomeClass a = "Instance generated by a string"; - Gregor Richards
Feb 19 2007
prev sibling parent reply kris <foo bar.com> writes:
Walter Bright wrote:
     a = b;
 
 is replaced with:
 
     a.opAssign(b);
 
 not:
 
     a = a.opAssign(b);
 
 The return value of opAssign comes in to play with:
 
     c = a = b;
 
 which is rewritten as:
 
     c = a.opAssign(b);
Doh! Doh! Doh! My bad; I saw this elsewhere and just assumed it would operate correctly. The syntax, however, is very clean. Importantly, it supports the unification or /centralization/ of all those 'new' invocations. I'd go so far as to say such a syntax could represent a bridge between OO and scripting: ---- String s = "mystring"; ---- ---- File f = "/foo/bar.d"; ---- ---- Regex r = "^(.*)$"; ---- There's a fairly wide range of simple applicability for this kinda' thing. Would be great if static opAssign() could support this, or some other operator were enabled? How about it?
Feb 19 2007
next sibling parent kris <foo bar.com> writes:
kris wrote:
 Walter Bright wrote:
 
     a = b;

 is replaced with:

     a.opAssign(b);

 not:

     a = a.opAssign(b);

 The return value of opAssign comes in to play with:

     c = a = b;

 which is rewritten as:

     c = a.opAssign(b);
Doh! Doh! Doh! My bad; I saw this elsewhere and just assumed it would operate correctly. The syntax, however, is very clean. Importantly, it supports the unification or /centralization/ of all those 'new' invocations. I'd go so far as to say such a syntax could represent a bridge between OO and scripting: ---- String s = "mystring"; ---- ---- File f = "/foo/bar.d"; ---- ---- Regex r = "^(.*)$"; ---- There's a fairly wide range of simple applicability for this kinda' thing. Would be great if static opAssign() could support this, or some other operator were enabled? How about it?
One note: an operator is suggested so that structs could take advantage of this also. Otherwise, some kind of 'property' assignment for a ctor might have done the trick?
Feb 19 2007
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
kris wrote:
 The syntax, however, is very clean. Importantly, it supports the 
 unification or /centralization/ of all those 'new' invocations. I'd go 
 so far as to say such a syntax could represent a bridge between OO and 
 scripting:
 
 ----
 String s = "mystring";
 ----
 
 ----
 File f = "/foo/bar.d";
 ----
 
 ----
 Regex r = "^(.*)$";
 ----
 
 There's a fairly wide range of simple applicability for this kinda' 
 thing. Would be great if static opAssign() could support this, or some 
 other operator were enabled?
 
 How about it?
I don't get it. Exactly what transformation are you looking for?
Feb 19 2007