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,
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.
[...]
>> 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.
Philippe