Struct copy and destruction

Brad Roberts braddr at puremagic.com
Sat Apr 9 11:52:23 PDT 2011


The next version of dmd will contain a number of bug fixes for struct ctor/dtor and lifetime management issues.  Unless
you're testing with the most current dmd code in git, I'd hold off.

On 4/9/2011 8:01 AM, Jason House wrote:
> I agree that the output ordering does not make sense. Try altering your example slightly so the program will segfault or do some other nonsensical thing if that is truly the order of operations. Once you have that, it'd make a great bugzilla entry! It definitely looks like a bug to me.
> 
> Morlan Wrote:
> 
>> The following code:
>>
>> //***************************************************
>> import std.conv, std.stdio;
>>
>> struct Slice {
>> 	int[] buff;
>> 	this(size_t len) {
>> 		buff = new int[len];
>> 	}
>> 	this(this) {
>> 		buff = buff.dup;
>> 		writeln("postblit");
>> 	}
>> }
>>
>> struct S {
>> 	string name;
>> 	Slice slc;
>> 	this(string name) {
>> 		writeln(name, " constructor");
>> 		this.name = name;
>> 	}
>> 	~this() {
>> 		writeln(name, " destructor");
>> 	}
>> }
>>
>> void main() {
>> 	auto s1 = S("s1");
>> 	auto s2 = S("s2");
>> 	s1 = s2;
>> 	writeln("after assignment");
>> }
>> //***********************************************
>>
>> produces the following output:
>>
>> s1 constructor
>> s2 constructor
>> postblit
>> s1 destructor
>> after assignment
>> s2 destructor
>> s2 destructor
>>
>> Note the "s1 destructor" line after "postblit". I cannot find any justification for the destructor
>> call in this place either in the TDPL book or in the Language Reference. Is this behaviour to be
>> expected? If so I would be grateful for the proper reference. Otherwise is it a bug?



More information about the Digitalmars-d mailing list