I was curious too, so found in Section 7.1.5.1 the description of
opAssign using a swap. That explains it I think.
Section 7.1.5.1 does not apply because it concerns the case where you define
your own
overload of the assignment operator. In my example the default assignment is
used.
The
On 04/09/2011 04:34 PM, Morlan wrote:
It sounds reasonable. But I cannot find information about this behaviour in the
Language Reference or TDPL book. Can you point to a relevant source?
Section 7.1.3.6 of TPLD talks about struct destructors, but like the
online documentation it only talks
Morlan h...@valentimex.com writes:
I was curious too, so found in Section 7.1.5.1 the description of
opAssign using a swap. That explains it I think.
Section 7.1.5.1 does not apply because it concerns the case where you
define your own overload of the assignment operator. In my example the
On 04/09/2011 10:00 AM, 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 =
Am 09.04.2011 11:47, schrieb spir:
On 04/09/2011 10:00 AM, 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);
The essence of my problem is why is the destructor called as a
result of the assignment in the first place? There is no
information about this behaviour in the language reference. Can
anyone explain this?
On 04/09/2011 12:42 PM, Morlan wrote:
The essence of my problem is why is the destructor called as a
result of the assignment in the first place? There is no
information about this behaviour in the language reference. Can
anyone explain this?
Because you assign a copy of s2 to s1 the struct
It sounds reasonable. But I cannot find information about this behaviour in the
Language Reference or TDPL book. Can you point to a relevant source?
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
Morlan h...@valentimex.com writes:
It sounds reasonable. But I cannot find information about this
behaviour in the Language Reference or TDPL book. Can you point to a
relevant source?
I was curious too, so found in Section 7.1.5.1 the description of
opAssign using a swap. That explains it I
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
11 matches
Mail list logo
