Boost logo

Boost :

From: Douglas Gregor (gregod_at_[hidden])
Date: 2003-10-05 11:31:43


On Sunday 05 October 2003 10:03 am, Philippe A. Bouchard wrote:
> Let's discuss the "ownership" paradigm:
>
> + perfect solution for 1d / 2d / nth d containers, ropes, neural networks,
> etc.;
> + is able to play the role of an auto_ptr<> and a weak_ptr<> at the same
> time;
> - it is possible to create dangling smart pointers in this case (dangling
> "weak_ptr<>s");
> - cannot be easily casted to other pointee types.

I don't believe I know the ownership paradigm; have a reference handy? And, of
course, that last bit worries me greatly: what kind of casting restrictions
are we talking about?

> > 1) Do you really need BOOST_GC_DEACTIVATE, if could users just
> > instead switch over to something like shared_ptr if they really don't
> > want to use GC? There's no need to allow (or require users to
> > understand) customization when alernatives already exist.
>
> If someone wrote his program with shifted_ptr and suddenly decides to
> accelerate his program he could simply define this macro, recompile & tada!
> it works like a normal reference count smart pointer & becomes faster.

Garbage collection can be faster than reference counting, but it all depends
on usage patterns. For instance, my GC-needing application has a phase where
it allocates a ton of memory, much of which won't be needed later. The next
phase runs over the internal representation many times (typical
compiler/static analyzer behavior). Reference-counting would be a killer
here, because in the second phase we incur all of the overhead of reference
counting but get little benefit from it, because memory isn't being
allocated/deallocated much.

I don't know where you want to take shifted_ptr, but I'm of the opinion that
it should do one thing (well). Macros aren't the place to support major
shifts in program behavior. If the user wants to be able to switch between
different smart pointers, she can use typedefs or policy-based pointers that
allow such things.

        Doug


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk