Re: toStringz note about keeping references

2012-10-16 Thread Charles Hixson
On 10/14/2012 04:54 PM, Ali Çehreli wrote: On 10/14/2012 04:36 PM, Andrej Mitrovic wrote: > On 10/15/12, Jonathan M Davis wrote: >> I'd have to see exactly what TDPL says to comment on that accurately > > Maybe I've misread it. On Page 288 it says: > > "An immutable value is cast in stone:

Re: toStringz note about keeping references

2012-10-15 Thread Kagamin
It's also possible that if a function reserves stack without clearing it, some old values may remain in the stack which were passed to other functions, so you'll have false pointers.

Re: toStringz note about keeping references

2012-10-15 Thread Kagamin
Probably a bug in GC, immutable data should be collected if not needed.

Re: toStringz note about keeping references

2012-10-15 Thread Jacob Carlborg
On 2012-10-15 01:56, Jonathan M Davis wrote: However, I believe that another option is to explicitly tell the GC not collect a chunk of memory (glancing at core.memory, I suspect that removeRoot is the function to use for that, but I've never done it before, so I'm not well acquainted with the

Re: toStringz note about keeping references

2012-10-14 Thread Jonathan M Davis
On Monday, October 15, 2012 02:04:44 Andrej Mitrovic wrote: > On 10/15/12, Jonathan M Davis wrote: > > snip > > Hmm ok, this sheds some light on things. > > If a C function takes a const pointer and has no documentation about > ownership then maybe it's a good guess to say it won't store that >

Re: toStringz note about keeping references

2012-10-14 Thread Andrej Mitrovic
On 10/15/12, Jonathan M Davis wrote: > snip Hmm ok, this sheds some light on things. If a C function takes a const pointer and has no documentation about ownership then maybe it's a good guess to say it won't store that pointer anywhere and will only use it as a temporary?

Re: toStringz note about keeping references

2012-10-14 Thread Jonathan M Davis
On Monday, October 15, 2012 01:36:27 Andrej Mitrovic wrote: > On 10/15/12, Jonathan M Davis wrote: > > I'd have to see exactly what TDPL says to comment on that accurately > > Maybe I've misread it. On Page 288 it says: > > "An immutable value is cast in stone: as soon as it's been > initialized

Re: toStringz note about keeping references

2012-10-14 Thread Ali Çehreli
On 10/14/2012 04:36 PM, Andrej Mitrovic wrote: > On 10/15/12, Jonathan M Davis wrote: >> I'd have to see exactly what TDPL says to comment on that accurately > > Maybe I've misread it. On Page 288 it says: > > "An immutable value is cast in stone: as soon as it's been > initialized, you may as we

Re: toStringz note about keeping references

2012-10-14 Thread Andrej Mitrovic
On 10/15/12, Jonathan M Davis wrote: > I'd have to see exactly what TDPL says to comment on that accurately Maybe I've misread it. On Page 288 it says: "An immutable value is cast in stone: as soon as it's been initialized, you may as well consider it has been burned forever into the memory stor

Re: toStringz note about keeping references

2012-10-14 Thread Jonathan M Davis
On Monday, October 15, 2012 00:51:34 Andrej Mitrovic wrote: > On 10/15/12, Jonathan M Davis wrote: > > Anything and everything with no references to it any > > longer should be up for collection. > > I think this is fuzzy territory and it's a good opportunity to > properly document GC behavior.

Re: toStringz note about keeping references

2012-10-14 Thread Jonathan M Davis
On Sunday, October 14, 2012 23:38:48 Andrej Mitrovic wrote: > toStringz takes a string (immutable(char)[]), and the GC will not > reclaim immutable data until app exit. If the GC never collects immutable data which has no references to it until the app closes, then there's a serious problem. Immu