Re: Smart pointers was RE: [GD-General] Compile times
Brought to you by:
vexxed72
From: brian h. <bri...@py...> - 2002-12-16 17:52:01
|
> >- 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 |