www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5546] New: Assigning and initializing structs from functions make more copies than necessary

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5546

           Summary: Assigning and initializing structs from functions make
                    more copies than necessary
           Product: D
           Version: D2
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: akb825 gmail.com



When initializing a struct from a function that returns by value, more copies
(calling the post blit and destructors) are called than are necessary. For
example, see the attached source file.

The output for TestCopy.d is currently:
Creating temp
Copying temp
Deleting temp
Creating copy
Copying copy
Deleting copy
Forwarding copy
Copying copy
Deleting copy
Returning global
Copying global
Deleting global
Deleting copy
Deleting temp

Ideally, the output should look like this:
Creating temp
Creating copy
Forwarding copy
Returning global
Copying global
Deleting global
Deleting copy
Deleting temp

When a struct is being initialized by the return value of a function, apart
from the memory being blitted over, no post blit or destructor should need to
be called, since semantically it's equivalent to directly initializing the
struct in the called function. This can be achieved by always returning a local
object and not destructing the local object being returned. In the case of
globalFunc(), which is returning a non-local object, a temporary would be made
before returning from globalFunc().

When assigning the returning value of a function to a struct that's already
initialized, additional optimizations can be made if no custom assignment
operator exists.

For example:
Test testVal;
testVal = function();

This will create the copy for the return value of function(), post blit
testVal, destroy the previous value of testVal, then destroy the return value
of function(). If Test or any of its members have an overridden assignment
operator, they must be called. However, in the case where there is no custom
assignment operator, the post blit of testVal and destruction of the return
value of function() can be omitted, since you are semantically moving the value
from the return value to testVal.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 07 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5546




Created an attachment (id=901)
Source file that demonstrates the behavior.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 07 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5546




After thinking about the problem a bit more, I have a couple things to add.

First, I should mention my second point for assigning the return value of a
function to an existing struct applies to all temporaries.

Test testVal;
testVal = Test("str");

can benefit from the same optimizations as

Test testVal;
testVal = function();

Second, it would be very useful to be able to mark the custom assignment
operator to have the same behavior on the above two cases as if there is no
overloaded assignment operator. (aka: skip the assignment and reduce it to a
blit + post blit and destruction of the old value when assigning from a
temporary) I would suggest something like putting " ignoreIfTemp" before the
opAssign definition, and would be ignored if members of the struct have custom
assignment operators without that property. This would allow one of the most
useful benefits of rvalue references from C++0x to be used without having to
add a whole new type qualifier.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 08 2011