On Wednesday, 6 November 2019 at 09:19:04 UTC, Jonathan M Davis
wrote:
DIP:
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1018.md
It looks like the release that added copy constructors to the
compiler was 2.086 back in May:
https://dlang.org/changelog/2.086.0.html
https://dlang
it a new malloc'ed address, your memcpy was
> >> essentially overwriting the original location with its own
> >> data.
> >
> > What I need was a deep copy, and I thought I could have done it
> > using postblit constructor. Thanks for clarification.
>
>
to the postblit, the
pointer is already pointing at the original location. Without
assigning it a new malloc'ed address, your memcpy was
essentially overwriting the original location with its own
data.
What I need was a deep copy, and I thought I could have done
it using postblit constructor.
ithout
assigning it a new malloc'ed address, your memcpy was
essentially overwriting the original location with its own
data.
What I need was a deep copy, and I thought I could have done it
using postblit constructor. Thanks for clarification.
I think copy constructor is less confusing though.
ithout assigning
it a new malloc'ed address, your memcpy was essentially
overwriting the original location with its own data.
What I need was a deep copy, and I thought I could have done it
using postblit constructor. Thanks for clarification.
On Tuesday, 5 November 2019 at 10:32:03 UTC, Ferhat Kurtulmuş
wrote:
On Tuesday, 5 November 2019 at 10:31:05 UTC, Ferhat Kurtulmuş
wrote:
On Tuesday, 5 November 2019 at 10:13:59 UTC, Mike Parker wrote:
[...]
Yep, it is obvious that my code is wrong. s1 and s2 point to
the same memory address
On Tuesday, 5 November 2019 at 10:13:59 UTC, Mike Parker wrote:
On Tuesday, 5 November 2019 at 08:47:05 UTC, Ferhat Kurtulmuş
wrote:
value of int which is 0. I wonder how new memory is allocated
without an explicit malloc here. Sorry for this noob question
in advance, I could not find any doc
On Tuesday, 5 November 2019 at 10:31:05 UTC, Ferhat Kurtulmuş
wrote:
On Tuesday, 5 November 2019 at 10:13:59 UTC, Mike Parker wrote:
[...]
Yep, it is obvious that my code is wrong. s1 and s2 point to
the same memory address. I could obtain my desired behavior
with copy constructor. The docum
On Tuesday, 5 November 2019 at 08:47:05 UTC, Ferhat Kurtulmuş
wrote:
value of int which is 0. I wonder how new memory is allocated
without an explicit malloc here. Sorry for this noob question
in advance, I could not find any doc mentioning a similar case.
int* vals = cast(int*)malloc
I am trying to learn behavior of postblit constructor. Below code
works as expected when I comment out malloc part of postblit
constructor. It writes 4 if malloc part of postblit constructor
is commented out. Otherwise it writes default init value of int
which is 0. I wonder how new memory is
t any postblit constructor called in there, the struct
seems just to get copied by a memcpy, can that be? Or is it a
bug? Shouldn't the postblit constructor get called there?
I'm not sure what you're expecting. The postblit is called when
an operation results in there being two
On Wednesday, 28 February 2018 at 18:27:49 UTC, Jiyan wrote:
On Wednesday, 28 February 2018 at 18:23:04 UTC, Jiyan wrote:
Hey,
i thought i had understood postblit, but in my Code the
following is happening (simplified):
struct C
{
this(this){/*Do sth*/}
list!C;
void opAssign(const C c)
{
"P
On Wednesday, 28 February 2018 at 18:23:04 UTC, Jiyan wrote:
Hey,
i thought i had understood postblit, but in my Code the
following is happening (simplified):
struct C
{
this(this){/*Do sth*/}
list!C;
void opAssign(const C c)
{
"Postlbit from C called".writeln;
// Do sth
}
}
Sry of course
ethods Add, Remove, erase are implemented here ...
}
The nodes are only allocated over malloc(). So i have to take
care of the initioalisation myself.
The problem is, that i found out by debugging, that it seems that
when i call val.opAssign(op) in constructNodeFrom(), there isnt
any postblit c
Am 31.03.2014 08:06, schrieb monarch_dodra:
On Monday, 31 March 2014 at 01:03:22 UTC, Carl Sturtivant wrote:
What about destructors, are they always called, or is this another
optimization if the struct is in it's default .init state?
In any case, there should be 1 destructor call for every ob
On Monday, 31 March 2014 at 01:03:22 UTC, Carl Sturtivant wrote:
What about destructors, are they always called, or is this
another optimization if the struct is in it's default .init
state?
AFAIK, a destructor is always called when an object goes out of
scope... unless, it's being moved out
D's structs don't have identity. That means, they can be moved
without notice at any point in the program. AFAIK the compiler
even does that when handling exceptions in a few cases (e.g.
with structs on the stack). Having moveable value types allows
for a lot of optimizations, both on the compi
Am 30.03.2014 21:35, schrieb Carl Sturtivant:
Context: struct values that are (non-ref) parameters & local variables.
Is there a way to arrange that a particular struct's special
constructors (postblit,destructor) should always be called even on move,
or on destruction of a default initialized
Context: struct values that are (non-ref) parameters & local
variables.
Is there a way to arrange that a particular struct's special
constructors (postblit,destructor) should always be called even
on move, or on destruction of a default initialized value,
temporary or not, etcetera, i.e. en
19 matches
Mail list logo
