Bug 5546 – Assigning and initializing structs from functions make more copies than necessary

Status
RESOLVED
Resolution
WORKSFORME
Severity
enhancement
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2011-02-07T23:31:00Z
Last change time
2015-12-09T11:16:55Z
Assigned to
nobody
Creator
akb825

Attachments

IDFilenameSummaryContent-TypeSize
901TestCopy.dSource file that demonstrates the behavior.text/plain721

Comments

Comment #0 by akb825 — 2011-02-07T23:31:56Z
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.
Comment #1 by akb825 — 2011-02-07T23:32:33Z
Created attachment 901 Source file that demonstrates the behavior.
Comment #2 by akb825 — 2011-02-08T00:42:20Z
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.
Comment #3 by lt.infiltrator — 2015-12-09T11:16:55Z
2.069 produces the desired output: ============ Creating temp Creating copy Forwarding copy Returning global Copying global Deleting global Deleting copy Deleting temp ============