On Wednesday, 17 February 2016 at 16:36:35 UTC, Matt Elkins wrote:
On Wednesday, 17 February 2016 at 07:10:15 UTC, ZombineDev
wrote:
The downside is that it really indicates that I didn't reduce
my buggy program properly. I'll hold out for the
live-object-destructor-call fix to see whether
On 17.02.2016 17:36, Matt Elkins wrote:
I tried this, and got the same issue. Actually, I was still able to
reproduce the original reported issue as well, which leads me to believe
either the bug was not actually fixed or (and this is more likely) I
screwed something up with my install. Do I
On 02/17/2016 11:37 AM, anonymous wrote:
> However, the code from this thread still prints
>
>
> Before 8
> Before 1
> Foo being destroyed: 0
> Before 2
> Foo being destroyed: 0
> Before 3
> Foo being destroyed: 0
> After Foo construction
> About to lose scope
> Foo being destroyed: 0
> Foo
On Wednesday, 17 February 2016 at 07:10:15 UTC, ZombineDev wrote:
The downside is that it really indicates that I didn't reduce
my buggy program properly. I'll hold out for the
live-object-destructor-call fix to see whether that corrects
my problem; I can just leak resources until then :).
dmd's behaviour is too confusing to accept. :) Filed:
https://issues.dlang.org/show_bug.cgi?id=15694
Ali
On Wednesday, 17 February 2016 at 02:44:04 UTC, Matt Elkins wrote:
On Wednesday, 17 February 2016 at 02:23:52 UTC, Ali Çehreli
wrote:
[...]
Oof. This strikes me as a "gotcha", that this happens even with
@disable this() as opposed to a compiler error. Is this only
for static arrays, or are
On Wednesday, 17 February 2016 at 02:23:52 UTC, Ali Çehreli wrote:
Since a static array must consist of .init values to begin
with, every move into its members must also trigger its
destructor if the type has elaborate destructor.
Oof. This strikes me as a "gotcha", that this happens even
On 02/16/2016 05:50 PM, Matt Elkins wrote:
On Tuesday, 16 February 2016 at 08:18:51 UTC, Ali Çehreli wrote:
When a temporary Foo object is moved into the array, the temporary
object is set to Foo.init. This temporary object lives on the stack.
In fact, all temporary Foo objects of Foo.this(int)
After some more time spent on (the non-reduced version of) this,
I think there is a decent chance I am really just experiencing
another manifestation of a bug I reported a little bit ago:
https://issues.dlang.org/show_bug.cgi?id=15661
The good news is that this is now marked as resolved, so
On Tuesday, 16 February 2016 at 10:45:09 UTC, Marc Schütz wrote:
On Tuesday, 16 February 2016 at 04:00:27 UTC, Mike Parker wrote:
On Tuesday, 16 February 2016 at 03:39:00 UTC, Matt Elkins
wrote:
On Tuesday, 16 February 2016 at 03:31:51 UTC, maik klein
wrote:
In D you can always call Foo.init
On Tuesday, 16 February 2016 at 08:18:51 UTC, Ali Çehreli wrote:
When a temporary Foo object is moved into the array, the
temporary object is set to Foo.init. This temporary object
lives on the stack. In fact, all temporary Foo objects of
Foo.this(int) live at the same location.
After Foo(8)
On Tuesday, 16 February 2016 at 04:00:27 UTC, Mike Parker wrote:
On Tuesday, 16 February 2016 at 03:39:00 UTC, Matt Elkins wrote:
On Tuesday, 16 February 2016 at 03:31:51 UTC, maik klein wrote:
In D you can always call Foo.init even with @disable this(),
Foo.init can be called implicitly
On 02/15/2016 06:09 PM, Matt Elkins wrote:
> * Where do those first three destroyed Foos come from?
I've printed some more information to come up with the following guess.
I am not sure whether it is correct or intended. Just a guess...
When a temporary Foo object is moved into the array,
On Tuesday, 16 February 2016 at 03:39:00 UTC, Matt Elkins wrote:
On Tuesday, 16 February 2016 at 03:31:51 UTC, maik klein wrote:
In D you can always call Foo.init even with @disable this(),
Foo.init can be called implicitly (not just explicitly)? If so,
why even have @disable this(), if it
On Tuesday, 16 February 2016 at 03:31:51 UTC, maik klein wrote:
In D you can always call Foo.init even with @disable this(),
Foo.init can be called implicitly (not just explicitly)? If so,
why even have @disable this(), if it offers no guarantees?
The first 3 destructor calls are from the 3
On Tuesday, 16 February 2016 at 02:09:15 UTC, Matt Elkins wrote:
I've been bitten again by my lack of understanding of the D
struct lifecycle :-/. I managed to reduce my buggy program to
the following example:
[...]
In D you can always call Foo.init even with @disable this(), The
first 3
I've been bitten again by my lack of understanding of the D
struct lifecycle :-/. I managed to reduce my buggy program to the
following example:
[code]
import std.stdio;
struct Foo
{
@disable this();
@disable this(this);
this(int valueIn) {value = valueIn;}
~this()
17 matches
Mail list logo
