[boost] Re: [pointer container] copyability

From: David Abrahams (dave_at_[hidden])
Date: 2005-04-27 14:55:32

"Thorsten Ottosen" <nesotto_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:uacnkw0cr.fsf_at_boost-consulting.com...
> | "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
>
> | > | Controversialness is in the eye of the beholder, and regardless,
> | > | Peter's right: by convention, the burden of proof lies with the
> | > | claimant.
> | > I disagree.
> | Then I will accept the burden of proof for my claim:
> | http://en.wikipedia.org/wiki/Burden_of_proof#Other_uses
> | http://www.nizkor.org/features/fallacies/burden-of-proof.html
>
> I don't see how that changes anything.

Wow, you're tough.  What sort of evidence would you accept as proof
that by convention, the burden of proof lies with the claimant?

> | > Pick up you're favourite book on OO and on STL and see if the
> | > programming techniques look alike.
> |
> | That's a very parsimonious explanation.  It would be nice if you'd
> | try to make it a bit clearer in the context of the question of
> | duplicating objects, and show how it justifies a choice to prohibit
> | ptr_containers from acting like proper values.
>
> the first reason must be its damn expensive without move-semantics.

I don't see how move semantics affects the cost of copying.  When you
have to copy, you have to copy.

Anyway copying std::vector<std::string> is similarly expensive to
copying ptr_container<whatever>.  I don't see what's wrong with that.

> the second reason is that value-based and OO programming are different
> and are best kept seperate; there are different idioms, different
> parts of the langauge is being used.  

That's a very paternalistic approach to library design, and rather
unprecedented.  Normally the only reason to make functionality that
you're implementing anyway hard to access is that it introduces
potential correctness problems, e.g. undefined behavior.  Efficiency
considerations are usually only used when deciding whether or not to
provide functionality at all. for example, that's why we don't have
std::vector::push_front.

Is there any amount of feedback from potential users that would
impress you?  So far a number of people in this thread have noted that
the interface seems unduly restrictive.  Have you heard from anyone
who said "thank you, Thorsten, for preventing me from unintentionally
doing something expensive?"  Can you imagine it hapenning?  For my
part, this design detail and the associated response to feedback would
prevent me from using the library altogether.  I'd rather roll my own,
should I need such a thing.

> copying is not that common an operation in OO programming; 

Maybe, but when you need it, you need it.

> it is in value-based programming etc etc.
>
> there has to be one default (with good and bad sides); I've chosen
> the default that I feel, based on experience, fits the goal of the
> library best; that decision was to make sure the programmer only
> made copies when he really wanted to.

As far as I can tell, it also prohibits him from making copies when he
really wants to.  There is no way to make a copy as part of an
agreggate unless you control that agreggate's definition.  There is no
way to stick a ptr_container in another container... etc.

> you're analogy with vector<string> don't quite fit IMO. assigning
> vector<string> might be quite efficient with very few heap-allocations
> taking place; 

Or it might be very expensive.

> assigning ptr_vector<Foo> would cost the same as copy-construction +
> deallocation.

It might only be necessary to do that for the elements and not the
outer container.

Anyway, I think I've made all the reasoned arguments that I can at
this point.  If nothing I've said makes an impression by now, I don't
think there's much point in continuing to try.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com