On Thu, 12 Feb 2015 12:10:21 +0000, Andrey Derzhavin wrote:

> if GC does not guarantee the calling of dtor we can't be sure that some
> textures will be destroyed.
> It will be followed by overflowing of the video memory.
> And it is obvious, becouse we have no way to detect when the objects are
> destroyed.
> The video memory will leaks.

that is the way garbage collection works.

On Thursday, 12 February 2015 at 12:29:47 UTC, Marc Schütz wrote:

> Exactly. That's why it's wrong to rely on the GC if you need deterministic resource management. It's simply the wrong tool for that.
>
> Unfortunately, the "right" tools are a bit awkward to use, for the time being. I still have hopes that we can finally get our act together and get a usable `scope` implementation, which can then be used to provide better library defined container types  as well as efficient reference counting.

If we can't relay on GC wholly, there is no need for GC.
All of the objects, that I can create, I can destroy manually by myself, without any doubtful GC destroying attempts.

On Thu, 12 Feb 2015 12:52:02 +0000, Andrey Derzhavin wrote:

> If we can't relay on GC wholly, there is no need for GC.
> All of the objects, that I can create, I can destroy manually by myself,
> without any doubtful GC destroying attempts.

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.

On Thursday, 12 February 2015 at 09:41:50 UTC, ketmar wrote:
> On Thu, 12 Feb 2015 09:26:12 +0000, Kagamin wrote:
>
>> That's a repetition of C++ atavism, that resource management == memory
>> management. IStream is a traditional example of a GC-managed object,
>> which needs deterministic destruction, and not because it consumes
>> memory, but because it encapsulates an unmanaged resource, it has
>> nothing to do with memory management, malloc and free.
>
> p.s. istream example is bad. what it does is simply highlighting the fact
> that there is no way to do deterministic management with GC.

Other languages manage to do it with scopes (e.g. using/lambda expressions) and phantom/weak references.

The only downsize it that it isn't as simple as a C++ destructor.

--
Paulo

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.

On Thu, 12 Feb 2015 13:21:07 +0000, Paulo  Pinto wrote:

> On Thursday, 12 February 2015 at 09:41:50 UTC, ketmar wrote:
>> On Thu, 12 Feb 2015 09:26:12 +0000, Kagamin wrote:
>>
>>> That's a repetition of C++ atavism, that resource management == memory management. IStream is a traditional example of a GC-managed object, which needs deterministic destruction, and not because it consumes memory, but because it encapsulates an unmanaged resource, it has nothing to do with memory management, malloc and free.
>>
>> p.s. istream example is bad. what it does is simply highlighting the fact that there is no way to do deterministic management with GC.
> 
> Other languages manage to do it with scopes (e.g. using/lambda expressions) and phantom/weak references.
> 
> The only downsize it that it isn't as simple as a C++ destructor.

but we have scopes and weak references in D too! i'm still enraged that i can't overload `new` and forced to use ugly `emplace!` and friends, but otherwise it's possible (albeit a little burdensome) to do refcounting for interfaces.

what is bad is that programmer has to be *very* careful with that. even seasoned programmers can made some errors here, that's why reference counting should be as much compiler-controlled as it can be.

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.

On Thursday, 12 February 2015 at 12:52:03 UTC, Andrey Derzhavin wrote:
> If we can't relay on GC wholly, there is no need for GC.
> All of the objects, that I can create, I can destroy manually by myself, without any doubtful GC destroying attempts.

Manual memory management should be possible in D, see for example https://github.com/Dgame/m3

On Thursday, 12 February 2015 at 11:10:35 UTC, ponce wrote:
> On Thursday, 12 February 2015 at 09:50:39 UTC, ketmar wrote:
>> On Thu, 12 Feb 2015 09:04:27 +0000, ponce wrote:
>>
>>> http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
>>> 
>>> I've also made one for "D can't do real-time because it has a
>>> stop-the-world GC"
>>> http://p0nce.github.io/d-idioms/#The-impossible-real-time-thread
>>> 
>>> And one for "D doesn't have ADTs"
>>> http://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching
>>
>> i believe that yor work needs more "official" highlighting. maybe it
>> worth having the links right on the front page of dlang.org
>
> Thanks :) but I'm not 100% sure about the correctness of it all. More like 80% :|.

You can put links in wiki: http://wiki.dlang.org/Articles

On Thursday, 12 February 2015 at 14:44:07 UTC, Kagamin wrote:
> On Thursday, 12 February 2015 at 12:52:03 UTC, Andrey Derzhavin wrote:
>> If we can't relay on GC wholly, there is no need for GC.
>> All of the objects, that I can create, I can destroy manually by myself, without any doubtful GC destroying attempts.
>
> Manual memory management should be possible in D, see for example https://github.com/Dgame/m3

And since today it is @safe wherever possible.