Community

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.

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

"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

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 +/

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

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.

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.