From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2003-10-05 09:03:37
Douglas Gregor wrote:
> Personally, I'd like to have one of these types. I don't care if it's
> called shifted_ptr, gc_ptr, or lazy_bum_ptr; it would help me greatly
lazy_bum_ptr<> will have to be negociated ;)
> // foo1.cpp
> class Pointee;
> // copy shifted_ptr<Pointee>'s around and such
> // foo2.cpp
> #include "Pointee.h" // get definition with traits
> // do stuff with shifted_ptr<Pointee>
> foo1.cpp and foo2.cpp both have shifted_ptr<Pointee>'s that act
> differently, causing very bad things to occur. The moral? Don't use
> traits to decide anything unless you also require the full definition
> of the class, or encode the policy in the shifted_ptr type.
Yeah this is also true. Let's discuss the "ownership" paradigm:
+ perfect solution for 1d / 2d / nth d containers, ropes, neural networks,
+ is able to play the role of an auto_ptr<> and a weak_ptr<> at the same
- it is possible to create dangling smart pointers in this case (dangling
- cannot be easily casted to other pointee types.
>> Any thoughts?
> I think it might be more fruitful to concentrate on a good,
> garbage-collected pointer. Two questions on this:
> 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.
> 2) The ability to explicitly destroy (or break) cycles would be
> very nice to have. Have you considered something akin to weak_ptr,
> that allows references but doesn't keep the target alive? (Note: I
> haven't thought about the implementation this _at all_, so I'll
> understand completely if you say it's infeasible or too costly).
This sounds a little bit like the ownership concept.
As for explicit destruction, it could create dangling smart pointers but it
would be at the user's discretion to perform the call.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk