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
> 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
> 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."
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk