From: Andrei Alexandrescu (See Website For Email) (SeeWebsiteForEmail_at_[hidden])
Date: 2005-04-26 23:48:04
Thorsten Ottosen wrote:
> In Lillehammer we rejected a policy-based smart pointer and it should never
> have gotten
> that far; I mean, David H. spent a lot of time writing the proposal and that
> time could have been
> saved.
Although I understand "rejection" is an overstatement, I wonder how the
committee deals with conflicts of interest. The ideological competitor
to policy_ptr is shared_ptr, and while the former has zero backing up
inside the committee, the latter is backed up by people who also get to
lobby and vote.
Now I'm not sure about others, but in such situation I'm biased. I mean,
if I were to propose and back up X, I would naturally believe X is
better than Y, Z, and even \Omega, and I won't be 100% objective. I
wouldn't be unreasonable, but as soon as it would come about things that
are hard to objectify, I'd assign more weight to negative arguments
against the competing design (policies are complicated, not enough
experience, too much choice etc.) than to arguments in favor of that
design (the inclusion relationship between policy_ptr and its technical
superiority that is obvious to me - but then hey, I'm biased). It's
human nature.
Case in point: shared_ptr fosters binary compatibility across calls to
shared libraries with different allocators and all that jazz. That's an
advantage, no doubt about that. But then people who proposed and back up
shared_ptr assign a lot of weight to that argument, which I believe
reflects their bias.
Here's why.
If people would really really believe this is a crucial advantage,
they'd be looking at the rest of the standard and they would shriek in
horror: "There's absolutely NO other component in the standard library -
no string, no vector, no map, no allocator, no NOTHING that offers the
same compatibility! But wait! There's even no standardization of
dynamically-linked libraries!" So if they'd really be objective, they'd
be into working on implementing the same stuff in containers and/or
allocators like white on rice. But the truth is, nobody cares about
string and vector not being passable across binary module boundaries.
Now really - nobody blinks an eye. But whenever talk comes about
shared_ptr, oh yes, that's essential! And that comes in conveniently
with the argument that there is too much configurability ("too many
notes") in policy_ptr, and therefore, what a wreck, each library will
just misuse that configurability to create incompatible smart pointer
stuff just for kicks. (At this point it is also very convenient to
forget about things like good ole default template arguments, policy
convertibility, and the upcoming type aliases.)
So the question would be, how does the committee deal with conflict of
interests like that? Because honest, if I were on the committee, every
misplaced comma in the shared_ptr proposal would stick like a sore thumb
to me, and I'd sure manage to convince others of the same.
Andrei