Ok. I hope it will not take months. :/

BTW:
I have a new strange behaviour by experiementing with structs.

This code http://dpaste.dzfl.pl/new#top
works fine, as long as i don't do _any_ operation after line 91.
If i activate one of the out comment operations or something else, the program works still fine but crashes after termination.

I use Windows 7, dmd 2.059 and compile with
-w -O -property -unittest -debug

I have no explanation.

I have tried various compiler flag combinations, even without.
But it still crashes. Seems to be a Windows bug.

On Saturday, 21 July 2012 at 20:48:16 UTC, Namespace wrote:
> I have tried various compiler flag combinations, even without.
> But it still crashes. Seems to be a Windows bug.

I'm stupid... I only compiles but not save my paste.

Here is the Code:
http://dpaste.dzfl.pl/d385c56b

On Saturday, July 21, 2012 22:41:10 Namespace wrote:
> Ok. I hope it will not take months. :/

Well, it's looking like it's going to take at least a month or two, but we'll see. It'll likely depend on how quickly Walter can complete what he's working on. He could have it done by the end of the month for all I know, but adding COFF support will take some time.

If you absolutely need the fixes that are currently on github sooner, you can always build the version on github. The easiest way to do that would probably be using DVM:

https://bitbucket.org/doob/dvm/wiki/Home

> BTW:
> I have a new strange behaviour by experiementing with structs.
> 
> This code http://dpaste.dzfl.pl/new#top
> works fine, as long as i don't do _any_ operation after line 91.
> If i activate one of the out comment operations or something
> else, the program works still fine but crashes after termination.
> 
> I use Windows 7, dmd 2.059 and compile with
> -w -O -property -unittest -debug
> 
> I have no explanation.

If you find a bug, please report it: http://d.puremagic.com/issues

- Jonathan M Davis

I'm not sure if it's a bug or my code is nonsense. ;)

On 07/21/2012 01:41 PM, Namespace wrote:
> Ok. I hope it will not take months. :/
>
> BTW:
> I have a new strange behaviour by experiementing with structs.
>
> This code http://dpaste.dzfl.pl/new#top
> works fine, as long as i don't do _any_ operation after line 91.
> If i activate one of the out comment operations or something else, the
> program works still fine but crashes after termination.
>
> I use Windows 7, dmd 2.059 and compile with
> -w -O -property -unittest -debug
>
> I have no explanation.

I was able to reproduce the segmentation fault when I compiled with -m32 under a 64 bit Linux environment. And this much is sufficient to reproduce the problem:

void main() {
    Foo f3 = new Foo();

    Test t = new Test(f3);
    writeln("exit main");    // <-- note the added line
}

One thing that I've noticed is that opAssign() is probably buggy because it overwrites this._ptr without taking care of it first (i.e. it is not doing '*_ptr = null'). But I don't think it is related to the main issue.

'Test' is a class having a struct member. The destructor of that member is accessing memory that is already gone. The last line in main makes it more clear how that destructor is accessing an already destroyed pointer:

this
this
exit main    <--
DTOR TEST
DESTROY SCOPED
make: *** [deneme] Segmentation fault

_sc_f._ptr points to f3, which is a local object in main.

Ali

Cool. Any idea how to fix it?
Check whether this._ptr! is null && *this._ptr! is null does not help.
Although I'm just experimenting, but it would be nice to have a solution.

First, my earlier writeln("exit main"); wasn't achieving much without putting everything before it in a scope (like it is below).

On 07/21/2012 03:12 PM, Namespace wrote:
> Cool. Any idea how to fix it?
> Check whether this._ptr! is null && *this._ptr! is null does not help.
> Although I'm just experimenting, but it would be nice to have a solution.

For Test to own a scoped_ptr member that holds on to a local class reference, it must be destroyed when leaving the same scope as the class reference (not potentially much later when the GC kicks in.)

One of guaranteeing it is using std.typecons.scoped:

import std.typecons;

void main() {
    {
        Foo f3 = new Foo();

        auto t = scoped!Test(f3);
    }

    writeln("exit main");
}

Now it is destroyed at the end of its scope (the scope is NOT needed for correctness, just for demonstration):

this
this
DTOR TEST
exit main    <--

Ali

The strange constructs in std.algorithm aren't something i like to use in real projects. Is there some other solution?

On Sunday, July 22, 2012 09:48:39 Namespace wrote:
> The strange constructs in std.algorithm aren't something i like to use in real projects. Is there some other solution?

And what's so strange about them? That they use ranges? If you start avoiding ranges, you're going to be missing out on a large portions of the standard library very quickly and will be left on your own to provide that functionality or provide it elsewhere. Phobos is very heavily range based and only becoming more so.

If you haven't read this tutorial on ranges yet, you probably should:

http://ddili.org/ders/d.en/ranges.html

- Jonathan M Davis