gamedevlists-general

Re: Smart pointers was RE: [GD-General] Compile times

[brian h. <bri...@py...>]

> >- non-deterministic destruction (a problem with general GC as well)
> 
> How so? With a real GC objects aren't deleted until the collector 
> gets around to freeing them, but with all the ref-counted smart 
> pointer classes I've seen they are deleted when the last reference is 
> released.

Non-deterministic was a poor choice of phrase.  More 
like "unpredictable" because, by definition, if you're using smart 
pointers you've opted to stop thinking about de-allocation of memory.  
So you're never quite sure when the "last reference" is released, since 
that can change as the code evolves.

> >- cascading destruction if you deref a root node
> 
> Why is this a problem?

Because along with "unpredictable de-allocation", it can lead to 
cascades that may cause a hiccup in your system.  If you have 
heavyweight destructors, having a bunch of them called instantly 
because you did this:

foo->pBar = NULL;

is both non-obvious (if you haven't been able to tell, I also abhor 
code that looks straightforward but may actually do a bunch of non-
obvious stuff) and annoying.
 
> Well, what are the options? In my experience automating reference 
> counting with smart pointers is a hell of a lot better than doing it 
> manually. 

My experience has been the opposite.  My anecdote can kick your 
anecdotes ass! =)

> Doing all the memory management manually with naked calls 
> to new and delete is feasible with discipline and some programming 
> conventions, but there are usually a few instances where this becomes 
> difficult.

Where is it difficult to rely on convention and discipline?

-Hook

RE: Smart pointers was RE: [GD-General] Compile times

[Wayne C. <wc...@re...>]

> Non-deterministic was a poor choice of phrase.  More
> like "unpredictable" because, by definition, if you're using smart
> pointers you've opted to stop thinking about de-allocation of memory.
> So you're never quite sure when the "last reference" is released, since
> that can change as the code evolves.

I know this a GD list rather than an 'any app list' but do you have a
problem with smart pointer\ref counting per se. or just when it relates to
game development? :)

> > Doing all the memory management manually with naked calls
> > to new and delete is feasible with discipline and some programming
> > conventions, but there are usually a few instances where this becomes
> > difficult.
> 
> Where is it difficult to rely on convention and discipline?

COM or a similar object model provides one source where the creator may not
necessarily be the one who destroys a particular object. The object may be
passed into a completely different part of the system which wants it to
stick around. A game environment is quite a controlled environment, but I've
heard of a few game engines that use COM (or similar) for their object
model.

Wayne
-Virus scanned and cleared ok

Re: Smart pointers was RE: [GD-General] Compile times

[brian h. <bri...@py...>]

> So, you've actually used manual ref counting Brian?

Yes, and it kinda sucks.  I don't even ref-count in my code.  I just 
know when and where stuff is allocated or freed.  
 
> >Where is it difficult to rely on convention and discipline?
> 
> The biggest problem is that it doesn't scale well. It's yet another 
> thing for new coders to learn and another thing for busy people to 
> remember to do. All other things being equal it's much better to 
> design the system so that you don't have to rely on a convention.

I sympathize and philosophically agree with this point of view, but at 
the same time in my experience there are usually enough trade offs with 
going with the "automated" approach that it simply ends up not being 
worth it.

I strongly feel that relying on discipline and solid interfaces is the 
right way to go, but I do understand it doesn't scale well because as 
teams grow you start getting fewer disciplined programmers and more 
programmers intent on "getting stuff done" instead of *gasp* thinking 
about what they're doing before they do it.

And as you pointed out elsewhere, this also depends a lot on how much 
dynamic memory allocationn you do.  Since I avoid it like the plague to 
minimize memory related errors (counter-argument: if I used a proper 
smart pointer class or GC system I wouldn't have to be so paranoid 
about such errors), it's much less of an issue for me.

In fact, for all my code, nearly all dynamic memory allocation is done 
at startup, all freeing is done at shut down, and there is almost no 
run-time allocation at all.  I try to use the stack as much as possible 
for objects that don't have a long life time.  I end up restricting 
dynamic allocation to when I don't know the size or number of objects I 
need, or if I'm hiding a derived class implementation (i.e. I'm using 
base class pointers and factory methods).

-Hook

Re: Smart pointers was RE: [GD-General] Compile times

[Ivan-Assen I. <as...@ha...>]

> Where is it difficult to rely on convention and discipline?

In the real world.

We never leave to convention what we can enforce via the interface.

Re: Smart pointers was RE: [GD-General] Compile times

[Jesse J. <jes...@mi...>]

At 11:51 AM -0600 12/16/02, brian hook wrote:
>  > >- non-deterministic destruction (a problem with general GC as well)
>>
>>  How so? With a real GC objects aren't deleted until the collector
>>  gets around to freeing them, but with all the ref-counted smart
>>  pointer classes I've seen they are deleted when the last reference is
>>  released.
>
>Non-deterministic was a poor choice of phrase.  More
>like "unpredictable" because, by definition, if you're using smart
>pointers you've opted to stop thinking about de-allocation of memory. 
>So you're never quite sure when the "last reference" is released, since
>that can change as the code evolves.

Yep, but I haven't found this to be an issue.

>  > >- cascading destruction if you deref a root node
>>
>>  Why is this a problem?
>
>Because along with "unpredictable de-allocation", it can lead to
>cascades that may cause a hiccup in your system.  If you have
>heavyweight destructors, having a bunch of them called instantly
>because you did this:
>
>foo->pBar = NULL;
>
>is both non-obvious (if you haven't been able to tell, I also abhor
>code that looks straightforward but may actually do a bunch of non-
>obvious stuff) and annoying.

I will grant you non-obvious (especially if you haven't used a 
garbage collected language much), but it seems to me any hiccups will 
come about at pretty much the same place in the game whether or not 
you use reference counting.

>  > Well, what are the options? In my experience automating reference
>>  counting with smart pointers is a hell of a lot better than doing it
>>  manually.
>
>My experience has been the opposite.  My anecdote can kick your
>anecdotes ass! =)

So, you've actually used manual ref counting Brian? InDesign used ref 
counting like crazy and the newer code that used smart pointers was 
noticeably cleaner than the old code.

>  > Doing all the memory management manually with naked calls
>>  to new and delete is feasible with discipline and some programming
>>  conventions, but there are usually a few instances where this becomes
>>  difficult.
>
>Where is it difficult to rely on convention and discipline?

The biggest problem is that it doesn't scale well. It's yet another 
thing for new coders to learn and another thing for busy people to 
remember to do. All other things being equal it's much better to 
design the system so that you don't have to rely on a convention.

   -- Jesse