May 22, 2006
Tom S wrote:
> Johan Granberg wrote:
> 
>> Tom S wrote:
>>
>>> Derek Parnell wrote:
>>>
>>>> I use the same technique. The idea that the only resource a ctor/dtor manages is RAM is plainly short-sighted.
>>
>> Agrees.
>>
>>> As for the texture example, they should be freed by some sort of a manager anyway - they have to be released before the rendering device anyway...
>>
>> Ok I think I get it. The destructors should only bee used when objects is deleted manually. right?
> 
> 
> That's what I'm doing. Otherwise dtors are just unreliable...


You might take a look at what Ares does in this regard? It allows one to intercept object collection, and lets you know whether the cleanup is of deterministic or "unspecified" nature. Invoking a dtor is only considered reliable in the deterministic case, so Ares allows one to trap and then optionally avoid dtor calls for that other case. One might use this mechanism to detect resource-leaks also.
May 22, 2006
kris wrote:
> You might take a look at what Ares does in this regard? It allows one to intercept object collection, and lets you know whether the cleanup is of deterministic or "unspecified" nature. Invoking a dtor is only considered reliable in the deterministic case, so Ares allows one to trap and then optionally avoid dtor calls for that other case. One might use this mechanism to detect resource-leaks also.

Sounds great :) Thanks for the info, I'll have to take a look at Ares.


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
May 23, 2006
On Mon, 22 May 2006 18:45:52 +0200, Tom S wrote:

> Derek Parnell wrote:
>> On Tue, 23 May 2006 01:59:14 +1000, Jarrett Billingsley <kb3ctd2@yahoo.com> wrote:
>>> Then, I have a static dtor which loops through all the textures and deletes them.
>> 
>> I use the same technique. The idea that the only resource a ctor/dtor manages is RAM is plainly short-sighted.
> 
> IIRC, Walter's point was that objects that hold some important resources should be manually memory-managed anyway. The GC is not guaranteed to delete any objects, even these which aren't pointed to from a global reference. This is because of the way the GC works. Maybe with a next GC incarnation (e.g. a compacting one) *hint*, *hint*, we'll get stronger guarantees ;)

I didn't mention 'GC'. I used the term 'dtor'. I do not equate the two pieces of functionality.

The 'dtor' is deconstruction functionality which should complement the construction function.

The 'GC' is a mechanism to collect 'garbage' RAM.

They are not the same thing.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
23/05/2006 10:05:19 AM
May 23, 2006
"Johan Granberg" <lijat.meREM@OVEgmail.com> wrote in message news:e4sj2e$43o$1@digitaldaemon.com...
>I came across this sentence in the specification
>
> "The garbage collector is not guaranteed to run the destructor for all unreferenced objects."
>
> This made me wonder in what circumstances the destructor WONT bee called. Basically I want to do this: An object stores a OpenGL texture (uint) and when the object gets collected/deleted I want to free the texture. I don't care about if the destructor will bee called on program exit, but I need some mechanism for freeing the textures during normal execution to prevent a video memory leak.
>
> So I need to know if I can trust the destructor to do this or it their is some other mechanism I can use.

Isn't this the type of problem the auto class was designed to address?

Of course, this does rely on matching the block structure of your application to the allocation/deallocation of resources.

It would be nice to have a more general mechanism than garbage collection, which allowed the programmer to register additional resources (other than memory) for automated management.


Tony
Melbourne, Australia


May 23, 2006
Derek Parnell wrote:
> I didn't mention 'GC'. I used the term 'dtor'. I do not equate the two
> pieces of functionality. 

And I never suggested equating them. Yet the discussion earlier touched the matter of whether the GC should call dtors and whether one should depend on dtors being called at program exit.

And you wrote:
> I use the same technique. The idea that the only resource a ctor/dtor manages is RAM is plainly short-sighted.

I assumed (perhaps incorrectly) that you wanted to depend on the GC to call dtors of objects that manage other resources than just RAM.

So if this is not the case, do you suggest that global objects should have their dtors called at program exit ? /* allowing the 'auto' modifier for global objects would be an option to implement it  */



It's clear that dtors should be called when you explicitly delete objects, but in case of explicit memory management, I'd still desist from using dtors for releasing resources. Why ? Let's assume that an object of class Foo holds a reference to another object, Bar. You manage the Foo objects by always freeing them manually using the 'delete' keyword and each Foo deletes its Bar in the dtor. But what happens if you create a bug and some Foo isn't deleted explicitly but instead the GC gets it ? A Bar could be released earlier and a Foo's attempt to release it again might be deadly ;)
In such a case, I'd prefer using a separate release() function orthogonal to the dtor. The worst that could happen then would be resource leaks. But they are smaller evil than pseudorandom crashes.

Thus I consider dtors and the GC to be strongly related. IMO the dtor should only be used in auto classes and some marginal cases (e.g. when an object allocates some memory using malloc).


> The 'dtor' is deconstruction functionality which should complement the
> construction function.

Indeed, and it shouldn't manage any resources other than RAM unless the class is declared as auto.


> The 'GC' is a mechanism to collect 'garbage' RAM. 
> 
> They are not the same thing.

That's clear.


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
May 24, 2006
Tom S wrote:
> 
>>> - they have to be released before the rendering device anyway...
>> Does this implies that the operating system does not reclaim video memory
>> at program exit? I have assumed that was the case but the answers in this thread left me uncertain.
> 
>  From my experience, not all OSes do that... I've seen a few crashes due to the GPU running out of texture memory ;D
> 
> 

Whoa, really? Seems almost too awful to believe with recent software and hardware. What OS and GPU would that be?

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 24, 2006
Bruno Medeiros wrote:
> Tom S wrote:
>>  From my experience, not all OSes do that... I've seen a few crashes due to the GPU running out of texture memory ;D
>>
>>
> 
> Whoa, really? Seems almost too awful to believe with recent software and hardware. What OS and GPU would that be?

If I remember correctly, it was Windows 98 Second Edition with a nVidia GPU.


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
May 25, 2006
Tony wrote:
> It would be nice to have a more general mechanism than garbage collection, which allowed the programmer to register additional resources (other than memory) for automated management.

Jarrett described such a mechanism he uses - an associative array he fills with resource references, then deletes them all in a static destructor.
May 25, 2006
Ben Hinkle wrote:
> Personally I would not rely on the using the GC to manage anything other than main memory. Why? If the user doubles their main memory but doesn't change their graphics memory then the GC might decide to collect object less often (since there's much more memory around) and so the graphics memory fill up before the GC decides it needs to do a collection. The GC should only be used to mange what it knows about: main memory. Anything else is a latent bug that depends on the end user's system configuration.
> Note that's actually why I don't have any destructors in Cx - they lull programmers into a false sense of security. In Cx the GC manages main memory and any other resource needs to be managed by the programmer. 

That's right. GC is a marvelous mechanism for managing memory, but not for other resources.
1 2
Next ›   Last »