[boost] Re: [pointer container] copyability

From: Bob Bell (belvis_at_[hidden])
Date: 2005-04-27 19:01:32

Thorsten Ottosen <nesotto <at> cs.auc.dk> writes:
> 
> "Bob Bell" <belvis <at> pacbell.net> wrote in message 
> news:loom.20050427T231515-202 <at> post.gmane.org...
> 
> | > the first reason must be its damn expensive without move-semantics.
> |
> | So is std::vector<std::map<std::vector<std::string>, std::set<int> > >,
> | std::vector<int> >. Should the standard library prevent users from using
> | copy construct/copy assignment syntax with this data structure?
> 
> good question. I'm pretty sure that performace does prevent you from using
> such a beast; so why bother ask the question.

Actually what prevents anyone from using it is that I got the braces
wrong. ;-)

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.

> | > 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.
> |
> | How do you know ptr_containers will be used in OO contexts? Why can't a user
> | use such containers to simply keep track of values?
> 
> he might; but the library is designed for use with OO; just like the "STL"
> is not really designed for OO. making it better at one thing, makes it worse 
> at another thing;
> you can't have both; that's life.

I disagree; STL works just fine in OO contexts. Why do you think it doesn't?

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

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)
are copyable. Second, you do allow copying anwyay, only through a
non-standard API.

> besides, there is no direct connection between what C++ allows you and
> what a library written in C++ allows you.

Not in any kind of iron-clad logic sort of way. But when I see a library
that goes against the grain of the language's spirit (for lack of a better
word), it makes me feel a little uncomfortable about that library.

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.

Bob