Community

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.

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

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

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

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