Boost Users :
From: Jean-François Brouillet (verec_at_[hidden])
Date: 2005-05-21 18:21:21
>>>> What is the name you would choose for the "addRef" parameter?
>>>> "managed" ? Or maybe, simply "addRef" after all, since you
>>>> would _assume_ by virtue of the symmetric behaviour of a
>>>> w.r.t a constructor, that whatever the constructor does, the
>>>> destructor un-does it, and whatever the constructor does NOT do,
>>>> the destructor does NOT un-do.
>>> Bad assumption with smart pointers. Ctors don't allocate
>>> resources, yet dtors deallocate them.
>> Which might only indicate that they are not so "smart" after
>> all... ;-)
> Clever quips aside, it indicates that your design principle doesn't
I fail to see the "generality" in the current design. An example where
it actually makes sense to not "addRef" on ctor but to "remRef" on dtor
would be most welcome.
> If you're arguing that the design of intrusive_ptr should be changed,
I don't have such pretensions. I was only suggesting to *rename* the
parameter ``addRef'' into something less confusing because of the
Initially, I thought it was a *bug*, hence the title of this thread.
I was told that it is not so, and that what I call a bug is actually
a design feature. That's fine with me. Except for the confusing name,
first, and the inability anyone, so far, has had to demonstrate a
useful example where this asymmetric behavior makes sense.
I'm all hears if you can convince me that the only road-block between
my goals and the boost xxxx_ptr family is just my lack of understanding.
> Whatever specific change you're arguing for may have merit,
> but not on the basis of ctor/dtor symmetry.
That's an *opinion*, probably as valid as mine, which is the
opposite, regardless of which has the most "mind-share".
My stance is that symmetry is at the very heart of the C++
object model. "destruct" is the precise opposite to "construct".
You can break it on whatever grounds you find suitable, but you
can't expect people to have an easy time a) not being surprised,
and b) understanding what was the overriding reason.
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