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

From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2005-04-27 15:27:30

On 4/27/05, David Abrahams <dave_at_[hidden]> wrote:
> "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.
> 

I needed to use a std::map<something, std::set<ExpensiveClass> >, at
first I saw it as:
std::map<something, boost::ptr_set<ExpensiveClass> >, and certainly it
wasnt the way to do it... I just didnt do it because I saw it couldnt
be done... correcting it to:
boost::ptr_map<something, boost::ptr_set<ExpensiveClass> >
So, well... I think it isnt that bad that it uses another syntax to
make copies of ptr_containers...
And I'm using ptr_containers all that time now...

> > 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
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> 

-- 
   Felipe Magno de Almeida
   UIN: 2113442
    email: felipe.almeida at ic unicamp br, felipe.m.almeida at gmail
com, felipe at synergy com
I am a C, modern C++, MFC, ODBC, Windows Services, MAPI developer
from synergy, and Computer Science student from State
University of Campinas(UNICAMP).
To know more about:
Unicamp: http://www.ic.unicamp.br
Synergy: http://www.synergy.com.br
current work: http://www.mintercept.com
"There is no dark side of the moon really. Matter of fact it's all dark."