GC has a "barbaric" destroyng model, I think

[ketmar via Digitalmars-d-learn]

On Thu, 12 Feb 2015 13:55:20 +0000, Andrey Derzhavin wrote:

> On Thursday, 12 February 2015 at 13:11:48 UTC, ketmar wrote:
>> sure. but when it comes, for example, for big data structures with
>> complex cross-references, you'll inevitably found that you either
>> leaking memory, or writing your own half-backed semi-working GC
>> realization.
>>
>> ah, good luck doing effecient refcounting on slices, for example. and
>> they aren't even remotely complex.
> 
> Well. What is the trouble if dtors are always (it is garanteed)
> called by GC before their phisical destroying?
> It will help to avoid many awkward situations.

that blocks various GC realizations or making 'em ineffective. yes, there 
is only one working GC realization for D now, but it doesn't mean that we 
can't have others in the future. even such seemingly simple task as 
calling dtor in the same thread where ctor was called is very difficult 
(how would you do that with concurrent GC, for example?). what to do with 
HUGE data structure, which is anchored in object with finalizer? (we now 
have ALOT of unused memory, yet still can't free it, as it is locked, 
waiting for finalizer call) and alot of other troubles.

actually, it's not a GC weakness, it's a bug in programmer's way of 
thinking. just stop thinking that GC is simply a "hidden free", that's 
not right. you can do manual resource management with `scope(exit)`, for 
example (just call `.close()` method or something), but you shouldn't 
expect that GC will (and should) do the same.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20150212/561cd4d0/attachment.sig>