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
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 Sun, 24 Jun 2012 14:56:20 -0400, Ellery Newcomer
ellery-newco...@utulsa.edu 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
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
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 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
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 calling gc_free during a collection, apparently.
Should I
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.
