Re: [boost] Re: Re: Policy-based smart pointers revisisted

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-01-21 08:32:33

From: "Paul Mensonides" <pmenso57_at_[hidden]>
>
> I don't want to propagate a war here, but Andrei's perception (of his
> perception) is not entirely unfounded either.  In the past, Andrei has
> raised some practical concerns with certain design strategies.  At that
> time, his opinion was derided based entirely on, from my perspective,
> religious devotion to an unproven concept.  Andrei asked for practical
> examples of the utility of those design strategies, and he was effectively
> told, "If you don't like it, don't use it."  I don't want to get into that
> old argument again, and that is not my intention.  I'm merely pointing out
> that Andrei got flack for presenting an opinion counter to many Boost
> developers' and standing by that opinion.  The fact is that there are many
> things that various Boost developers will argue over with religious fervor
> (i.e. another way of saying "political"), and I simply don't believe that
> people are entirely objective.  Their preferences influence their beliefs,
> and people typically don't take criticism well.  That is to be expected.
> Such is life.

Indeed. It would be nice if you include links to the relevant messages here,
by the way. I am _not_ saying that you are misrepresenting the MPL
discussion, your summary is close to what I recall, but such statements need
to be backed up with facts as a matter of principle.

If you feel particularly objective, you could even point to some of my posts
where I side with Andrei on this front.

It is not fair to take only the posts where some Boost developer disagrees
with Andrei and present that as some kind of unified Boost stance.

> The same thing looks like it is happening here with policy-based smart
> pointers.

No, the situation is quite different.

In the MPL case, Aleksey presented a design, and had to defend it against
criticisms. The controversial issue of whether the genericity is worth the
added complexity never got resolved to everybody's satisfaction, _but_ it is
Aleksey who is doing the work, so he gets to call the shots. That's how
Boost works. There can be no other way.

The PBSP first and foremost problem is that _someone has to do the work_.

> It seems to me that arguments are being manufactured to preclude
> the concept of a policy-based smart pointer (such as incompatibilities and
> the supposed complexity of interface--neither of which I personally think
is
> significant) precisely because it isn't 'shared_ptr' or that it would
> subsume 'shared_ptr'.  That may or may not be the case, but that is how it
> comes off to me, and I can see how it would come off that way to others.

I've never liked the "shared_ptr vs smart_ptr" debate. It is completely and
utterly unproductive. If I had to Do All The SP Work(tm), I'd still keep
shared_ptr, and I'd not attempt to subsume it with smart_ptr simply because
I think that it would be detrimental to stretch smart_ptr to make it do
things it isn't designed to do. But that's another story.

The main reason that I don't like the "shared_ptr vs smart_ptr" game is that
many PBSP proponents think that it is necessary to compare smart_ptr against
shared_ptr, either pointing out how shared_ptr doesn't handle X and
smart_ptr does, or trying to demonstrate how smart_ptr can subsume
shared_ptr. Many of these arguments contain inaccuracies which, in turn,
force someone to "defend" shared_ptr. Repeat ad infinitum. No value added.

> This is precisely why I think that we need both forms.

So do I. So what?