Re: [boost] Re: [pointer container] copyability

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-04-28 08:21:43

From: "Thorsten Ottosen" <nesotto_at_[hidden]>
> "Bob Bell" <belvis_at_[hidden]> wrote in message 
> news:loom.20050428T013921-284_at_post.gmane.org...
> | Thorsten Ottosen <nesotto <at> cs.auc.dk> writes:
> 
> | Seriously, performance may or may not prevent me from using it, depending
> | on what it's for and how I'll use it. But performance does not take away
> | copy construction or copy assignment.
> 
> as I said, I don't think the performance argument is the most important.
[snip]
> | > | One of the great strengths of C++ is that it doesn't try to force the
> | > | programmer into any one programming paradigm. Your justification for
> | > | denying ordinary copy syntax is against this spirit.
> | >
> | > so you would be against scoped_ptr being not copyable?
> |
> | The absence of copying in scoped_ptr is not about enforcing or even
> | encouraging a programming paradigm. Scoped_ptr denies copying because of
> | what scoped _ptr _is_: a non-copyable type.
> 
> but we could have made it copyable just like you're trying to say we can make
> pointer containers copyable.

Are you seriously making that point?  scoped_ptr wouldn't be
scoped_ptr if it copied.  A pointer container remains every bit a
pointer container if it provides the usual spellings for copying
and assignment.

> at the bottom line, C++ copies too much and sometimes its just a benefit to be 
> made aware
> of that fact

Why should one library assume the pedagogical role of teaching
C++ programmers that C++ copies too much?  If you're that
concerned that people will copy pointer containers more than they
realize, with resulting performance problems, and perhaps lead to
abandoning the library, just add a manifest constant controlled
diagnostic when copies occur.

> | The same argument cannot be made for ptr_container, for two reasons. First,
> | ptr_container is a kind of container,
>                          ^^^^^^^^^^^^^^^^
> | and containers (as I understand them)
> ^^^^^^^^^^^^^^
> 
> as you remark, pointer containers are "a kind of " containers; so they are not 
> containers in the usual sense.

Why are you picking at nits like this?  Yep, it's "a kind of"
container, so one expects it to work like most every other
container one encounters.

> | One thing I'm wondering about which I don't think I've seen discussed in
> | this thread yet is: suppose you added copy operations to ptr_container.
> | Who would be harmed? Before you say "anybody who uses those operations,
> | because their performance is degraded," keep in mind that those people are
> | also benefitting from those operations. I'm asking about people who are
> | harmed without receiving any benefit.
> 
> you can't assume that all people are going to see your perceived benefits as 
> their own benefits.
> 
> making a type copyable or not affects how you design your program; I don't 
> believe it is sound
> not to be conscious about cloning of class hierarchies.

So instrument the operations that trouble you.  You could offer
an option to disable those operations, so long as those that want
them can enable them.

> in 10 lines of code you can have a copyable ptr_vector if you want, I don't 
> see why you can't
> just do that if you want that?

Because then most users of the library will need to write that
same code.  That means it should be in the library.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;