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 destructor 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 generalize.
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 asymmetric behavior. 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. Many thanks. -- JFB