Re: [boost] Re: Smart pointers: One more implementation +question

From: Pavel Vasiliev (pavel_at_[hidden])
Date: 2003-02-06 09:59:12

Andrei Alexandrescu wrote:

>> (in short: "Parameterization discourages users", "Template parameters
>> affect the type", "Having a single pointer type is important for
>> stable library interfaces". Sorry for possible out-of-context citation)

> Your agreement with the statements above would naturally lead you to NOT
> define yet another smart pointer, but instead, to work on perfecting
> shared_ptr. Convictions and actions should best work in agreement. "One
> Pointer Type is Good" and "I Have One More Pointer Implementation For You
> Guys to Look At" don't go together. So if you were to start work on a
> project now, what smart pointer would you use for a stable library
> interface? If you'd use yours, does it mean you consider it intrinsically
> better than shared_ptr? I think many would disagree for a variety of
> objective reasons. (Some of them I mentioned in a reply to shifted_ptr, and
> if I'm not wrong they apply to your work as well.) Then you might say, yes,
> it all depends on what the project's context is. Then I come and say, /my
> point exactly/.

boost::shared_ptr must retain compatiblility with older versions.
It can not be turned to another ways without harming many current
users. I tried to write a more generic implementation that still
replicates the strongest features of shared_ptr.

For example, refc_ptr supports true intrusive ptrs with their little
overhead. And it even supports semi-intrusive ptrs that are a clear
replacement for intrusive ones. In this sense, yes, I think that
refc_ptr is better than shared_ptr.

I propose the idea. If it deserves living (that is still to be
verified), I don't mind if it is implemented in some other smart
pointer, for example policy-based one.

> The whole purpose of smart_ptr is to devise a framework that makes it easy
> for people like *you* to create their own smart pointers without having to
> fight their way through all the syntactic and semantic gunk.

Yes. In one of my projects I used 4 different types of smart pointers.
3 of them were std::auto_ptr, COM-ptr and a self-made library-specific
ptr. It would be nice to have all these pointers in one framework like
Loki::SmartPtr.

But I still sure that pointers of the family like boost::shared_ptr
(and my refc_ptr) are another story. Fighting through the syntactic,
semantic and portability problems is challenge, but their
functionality is even harder challenge.

> Not that I don't think the fun aspect ain't important. I think this is my
> main problem with Loki::SmartPtr: people seem to have more fun writing
> smart pointers from scratch, than writing policies for it. If that persists
> over time, then by all means Loki::SmartPtr ain't that cool. Seriously: fun
> *is* important :o).

:-) This my refc_ptr is about 2 years old. I improved it from time to
time, after looking to boost, or reading Modern C++ Design. All this
were for my own pleasure, you are right. For me your Loki::SmartPtr
was rather a collection of well-defined considerations and hints. Most
probably, I am not alone in this... I think you also designed
Loki::SmartPtr mostly for your own fun :-).

Pavel