[boost] Re: [pointer container] copyability

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-04-27 15:48:11

"David Abrahams" <dave_at_[hidden]> wrote in message 
news:uwtqot2ob.fsf_at_boost-consulting.com...
| "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?

as some of your links says in the text, it is sometimes hard to agree who
has the burden of proof.

in this case I don't see that you are a claimant if you want to disallow 
copying anymore than
if you would allow copying.

| > | > 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.

current containers will make temporary copies when moving
objects around.

| 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?

sure, but how many of these people participated in the review?

| 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?

not those exact words, but I've heard people say they agree on the design.

I personally don't consider the "expensive copying" argument the most 
important.

| 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.

well, its quite easy to derive from one of the classes and
add copy operations.

| > copying is not that common an operation in OO programming;
|
| Maybe, but when you need it, you need it.

so you just clone() the container.

you might look at scoped_ptr<T> too. We could have made that do deep-copy too,
but we didn't.

Sometimes not copying by default is just better; C++ copies too much by
default; that's why we're looking at "explicit class".

| > 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.

it doesn't prohibit copying, it prohibits copies by use of copy-construction 
and copy-assignment,
but yes, its a tradeoff.

|  There is no way to make a copy as part of an
| agreggate unless you control that agreggate's definition.

yes, you can't use make_pair() for example.

| There is no
| way to stick a ptr_container in another container... etc.

correct, you have to use another pointer container.

-Thorsten