On 3/18/16 11:07 AM, Andrea Fontana wrote:
On Friday, 18 March 2016 at 15:03:14 UTC, Steven Schveighoffer wrote:
Structs are contained completely within the class instance memory
block (e.g. the OP's code). Classes are references. They are not
destroyed when you destroy the holder, that is left
Hi !
I wonder if i can rely on this code :
http://dpaste.dzfl.pl/745cc5b1cdfb
There's two questions:
1) Is dtors always called in reverse order ?
2) Is all the dtors always called when i call destroy ?
Thanks for a reply !
On Friday, 18 March 2016 at 14:53:20 UTC, Steven Schveighoffer
wrote:
On 3/18/16 7:44 AM, Nicholas Wilson wrote:
On Friday, 18 March 2016 at 10:20:40 UTC, Temtaime wrote:
Hi !
I wonder if i can rely on this code :
http://dpaste.dzfl.pl/745cc5b1cdfb
There's two questions:
1) Is dtors always
On Friday, 18 March 2016 at 10:20:40 UTC, Temtaime wrote:
Hi !
I wonder if i can rely on this code :
http://dpaste.dzfl.pl/745cc5b1cdfb
There's two questions:
1) Is dtors always called in reverse order ?
yes
2) Is all the dtors always called when i call destroy ?
yes. destroy calls __dtor()
On Friday, 18 March 2016 at 15:03:14 UTC, Steven Schveighoffer
wrote:
On 3/18/16 10:58 AM, Andrea Fontana wrote:
On Friday, 18 March 2016 at 14:53:20 UTC, Steven Schveighoffer
wrote:
On 3/18/16 7:44 AM, Nicholas Wilson wrote:
On Friday, 18 March 2016 at 10:20:40 UTC, Temtaime wrote:
Hi !
I
On 3/18/16 7:44 AM, Nicholas Wilson wrote:
On Friday, 18 March 2016 at 10:20:40 UTC, Temtaime wrote:
Hi !
I wonder if i can rely on this code :
http://dpaste.dzfl.pl/745cc5b1cdfb
There's two questions:
1) Is dtors always called in reverse order ?
yes
2) Is all the dtors always called when i
On 3/18/16 10:58 AM, Andrea Fontana wrote:
On Friday, 18 March 2016 at 14:53:20 UTC, Steven Schveighoffer wrote:
On 3/18/16 7:44 AM, Nicholas Wilson wrote:
On Friday, 18 March 2016 at 10:20:40 UTC, Temtaime wrote:
Hi !
I wonder if i can rely on this code :
http://dpaste.dzfl.pl/745cc5b1cdfb
On Friday, 18 March 2016 at 15:07:53 UTC, Andrea Fontana wrote:
On Friday, 18 March 2016 at 15:03:14 UTC, Steven Schveighoffer
wrote:
On 3/18/16 10:58 AM, Andrea Fontana wrote:
On Friday, 18 March 2016 at 14:53:20 UTC, Steven
Schveighoffer wrote:
On 3/18/16 7:44 AM, Nicholas Wilson wrote:
On Wednesday, 22 October 2014 at 23:11:14 UTC, Ali Çehreli wrote:
On 10/22/2014 04:05 PM, eles wrote:
And the compiler swallows this without even barking?
The compiler must obey an alias this inside Scoped.
I've thinking for a way do disallow this but haven't been able
to spend much time on
Am Thu, 23 Oct 2014 12:15:13 +
schrieb Marc Schütz schue...@gmx.net:
Yet another use case for borrowing.
Cool, how does it keep the original struct alive though, if it
isn't stored anywhere? Or will it error out when you attempt
to use the dangling pointer to the object?
--
Marco
On Thursday, 23 October 2014 at 13:03:08 UTC, Marco Leise wrote:
Am Thu, 23 Oct 2014 12:15:13 +
schrieb Marc Schütz schue...@gmx.net:
Yet another use case for borrowing.
Cool, how does it keep the original struct alive though, if it
isn't stored anywhere? Or will it error out when you
C++ versions:
{ //displays ~C~B~A
A foo;
B bar;
C *caz = new C();
delete caz;
}
std::cout std::endl;
{ //displays ~C~B~A
std::unique_ptrA foo = std::make_uniqueA();
std::unique_ptrB bar =
On Wednesday, 22 October 2014 at 15:45:02 UTC, eles wrote:
D version with structs:
{ //display ~C~B~A
A foo;
B bar;
C *caz = new C();
delete caz;
}
as expected.
On Wed, 22 Oct 2014 16:49:20 +0100, eles e...@eles.com wrote:
On Wednesday, 22 October 2014 at 15:45:02 UTC, eles wrote:
D version with structs:
{ //display ~C~B~A
A foo;
B bar;
C *caz = new C();
delete caz;
}
as expected.
with the DeleteExpression, as the
destructor is not being run by the garbage collector, meaning
all references are valid.
But Scoped!A is on the stack?
So why wasn't the eles' destructor order in reverse if Scoped is
a struct and calls explicit destroy(B) then destroy(A)?
https://github.com/D
On Wednesday, 22 October 2014 at 17:13:35 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 22 October 2014 at 16:55:41 UTC, Regan Heath
So why wasn't the eles' destructor order in reverse if Scoped
is a struct and calls explicit destroy(B) then destroy(A)?
Maybe it's the writeln() inside
On Wednesday, 22 October 2014 at 15:45:02 UTC, eles wrote:
D version:
{ //displays ~A~B~C
A foo = scoped!(A)();
B bar = scoped!(B)();
C caz = new C();
destroy(caz);
}
Why the objects are not destroyed in the inverse order of their
On 10/22/2014 08:45 AM, eles wrote: C++ versions:
{ //displays ~C~B~A
A foo;
B bar;
C *caz = new C();
delete caz;
}
std::cout std::endl;
{ //displays ~C~B~A
std::unique_ptrA foo = std::make_uniqueA();
On Wed, 22 Oct 2014 18:03:44 +
anonymous via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
On Wednesday, 22 October 2014 at 15:45:02 UTC, eles wrote:
D version:
{ //displays ~A~B~C
A foo = scoped!(A)();
B bar = scoped!(B)();
C caz = new
On Wednesday, 22 October 2014 at 18:14:54 UTC, ketmar via
Digitalmars-d-learn wrote:
yes, this is the case. i believe that this should be explicitly
documented in `scoped` ddocs. documentation examples using
'auto', but there is no mention that this is what *must* be
used.
This is too
On Wed, 22 Oct 2014 18:44:26 +
via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Wednesday, 22 October 2014 at 18:14:54 UTC, ketmar via
Digitalmars-d-learn wrote:
yes, this is the case. i believe that this should be explicitly
documented in `scoped` ddocs.
On Wednesday, 22 October 2014 at 18:03:44 UTC, anonymous wrote:
On Wednesday, 22 October 2014 at 15:45:02 UTC, eles wrote:
`foo` should be a `Scoped!A`. When it's typed as `A`, the
`Scoped!A` that is returned by `scoped`, is destructed
immediately (and the reference leaks, I guess).
Just
On Wednesday, 22 October 2014 at 18:03:44 UTC, anonymous wrote:
On Wednesday, 22 October 2014 at 15:45:02 UTC, eles wrote:
D version:
`foo` should be a `Scoped!A`. When it's typed as `A`, the
`Scoped!A` that is returned by `scoped`, is destructed
immediately (and the reference leaks, I
On 10/22/2014 04:05 PM, eles wrote:
And the compiler swallows this without even barking?
The compiler must obey an alias this inside Scoped.
I've thinking for a way do disallow this but haven't been able to spend
much time on it today.
Why Scoped!A is convertible to A, then?
So that
24 matches
Mail list logo
