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.
signature.asc
Description: PGP signature
