On 06/26/2012 12:41 PM, Steven Schveighoffer wrote:
I want to red flag this code for another reason.
You must *never* access GC-allocated references in a destructor, to do
so will make the program crash randomly.
The docs should be so assertive (not that I read them or anything).
The destr
On Sun, 24 Jun 2012 14:56:20 -0400, Ellery Newcomer
wrote:
On 06/24/2012 02:53 AM, Dmitry Olshansky wrote:
I think no, as any with operation involving GC. For instance while you
are removing elements table may decide to rehash itself and that means
it may trigger allocation.
okay, it loo
On 06/24/2012 01:56 PM, Ellery Newcomer wrote:
Come to think of it, though, shouldn't the standard library provide an
aa implementation that doesn't rely on the gc?
ah, screw it, I'll just write my own.
On 06/24/2012 02:53 AM, Dmitry Olshansky wrote:
I think no, as any with operation involving GC. For instance while you
are removing elements table may decide to rehash itself and that means
it may trigger allocation.
okay, it looks like my [inherited] code is using aa's to map D objects
to C
On Sunday, June 24, 2012 11:53:37 Dmitry Olshansky wrote:
> On 24-Jun-12 08:15, Ellery Newcomer wrote:
> > this code:
> >
> > class X{
> >
> > string[string] s;
> > this() {
> >
> > s["s"] = "S";
> >
> > }
> > ~this() {
> >
> > s.remove("s")
On 24-Jun-12 08:15, Ellery Newcomer wrote:
this code:
class X{
string[string] s;
this() {
s["s"] = "S";
}
~this() {
s.remove("s");
}
}
void main() {
X x = new X();
}
produces this:
core.exception.InvalidMemoryOperationError
because the aa is c
I've been having the same problem as well, but I never figured
out the link to the remove() call in the destructor. The only
solution I've found is to use GC.removeRoot() on the table, but
it's an untested and potentially dangerous solution.
