Boost Users :
From: Jean-François Brouillet (verec_at_[hidden])
Date: 2005-05-18 17:15:44
>> intrusive_ptr(T * p, bool add_ref = true);
>> Effects: if(p != 0 && add_ref) intrusive_ptr_add_ref(p);.
>> Postconditions: get() == p.
> Right, so you can't call it a bug if the implementation does
> exactly as stated. ;-)
X * x = new X ;
intrusive_ptr<X> px(x) ;
Here, x is destroyed, and rightly so.
Now (same example as yesterday):
X * x = new X ;
intrusive_ptr<X, false> px(x) ;
Here, x is destroyed *too*, even though the additional "false"
was supposed to mean: "please, don't mess-up with refCounts at
all, *I* have everything under control.
If preserving the current intrusive_ptr semantics is paramount
(as I kind of sense it is now), some confusion could be avoided
by renaming "addRef" to something less ambiguous or suggestive.
The question is not _how_ it does what it does (it does it by
adding 1 to the refCount, or not, hence that dubious name) but
_what_ it does when that argument is set to false.
If it is difficult to find a name to describe _what_ it does
in such a case (which might point to a poorly understood use-case)
then the next best thing is probably a catch-all word such as
"standard", which, by negation (=false) means a clear warning:
"What you're about to do when setting ``standard'' to false is,
by definition non standard, and you *must* understand so and so
to avoid being caught with your pants down"
> I'm pretty sure that a shared_ptr-based port can closely
> approximate the original,
"approximate"! That's the key. I don't want to "approximate".
Either I find a way to *completely* hide the smart pointer modulo:
- the initial "new X"
- "on the fly" packaging of ``this'' when required __from within__
(ie when passing ``this'' to some other unrelated method of
some other class that requires an _envelope_ as argument and
not a _body_, since my whole API, once translated from Java,
will only expose _envelopes_)
or I will go the painful Boehm's road and use conservative GC.
> but a custom smart pointer would probably be a better choice for
> idiomatic Java code.
I wish you are right! I'll give myself all the evenings and
week-ends until the end of May. If I fail to come up with
something that is acceptable, I'll go conservative, because
"Real artists ship!" :-)
> As for intrusive_ptr, its main strength is that it has the size
> of a pointer.
HoHum ...scoped_ptr shares this "exclusive" strength ...
> Adding a boolean would likely meet serious opposition.
Never mind the opposition. Is that the right thing to do or not?
Since I don't understand your use cases, I just can't comment.
> Your requirements are very interesting, however, and point to a
> shared/intrusive hybrid along the lines of:
> template<class T> class intrusive_ptr_2
> T * px_;
> intrusive_ptr<Object> pn_;
> // insert smart pointer boilerplate here ;-)
I'm not sure I understand. pn_ is supposed to perform the
refCounting part, and px_ is supposed to be the actual _body_ ?
> It's an intrusive pointer that's close to shared_ptr in expressive
> power; you can use it to point to a subobject, for example.
> Extending intrusive_ptr to accommodate the above along the lines of
> template<class T, class U = void> class intrusive_ptr
> T * px_;
> U * pn_; // not present when U == void
> could be feasible.
I don't see how this relates to the problem of providing an
indirection ("pointer") construct such that, once you've
xxxx_ptr<X> p(new X) ;
you're done, once and for all, never asking _user_ code to deal
with the intricacies of your xxxx_ptr *implementation*.
When you come to think of it, a garbage collector is meant
to provide _automatic_ garbage collection, not semi-automatic,
Compounding the problem of memory management with additional
idiosyncratic problems is not going to free that one remaining
brain cell out of a total of 7, that holds the whole universe
under your current consciousness level. A bad guarantee is worse
than no guarantee at all.
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net