Boost logo

Boost :

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
> >
> > | "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:
> > |
> > |
> >
> > 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
> _______________________________________________
> Unsubscribe & other changes:

   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:
current work:
"There is no dark side of the moon really. Matter of fact it's all dark."

Boost list run by bdawes at, gregod at, cpdaniel at, john at