From: Ivan Vecerina (ivec_at_[hidden])
Date: 2006-04-24 07:52:11
"Thorsten Ottosen" <thorsten.ottosen_at_[hidden]> wrote in message
: Ivan Vecerina wrote:
: > "Thorsten Ottosen" <thorsten.ottosen_at_[hidden]> wrote in message
: > news:444BDD01.5030601_at_dezide.com...
: > : Ivan Vecerina wrote:
: > ....
: > : > : Here are some other examples of classes that has been designed
: > : > : as over-encapsulated:
: > :
: > : > : - standard containers
: > : > In what way?
: > :
: > : Lack of inplace-construction or construction with uninitialized
: > : or acceptance of a buffer to give to the vector.
: > :
: > : This hurts performance in libraries such as serialization or asio.
: > All STL containers are strict about ensuring proper construction/
: > initialization of their contents. I think that this is a consistent
: > choice.
: That's irrelevant.
: > Is the performance of those libraries measurably hit?
: Yes (I havn't looked at how std::vector is used in ASIO, but I can't see
: how it could get around the problem).
: > If so, maybe you want a pod_vector, which will also benefit
: > from relying on realloc. No big deal.
: It's not just for PODs.
How would you fill a non-POD vector with uninitialized data ?
: > : > If we really want to provide member functions for ease-of-use
: > : > purposes, then I believe that we should make this a separate
: > : > class from the ptree "container".
: > : > It would be pretty straightforward to do so.
: > :
: > : In the same manner operator() could have been left out
: > : of std::map<T>, yet is is one of the most convenient functions.
: > I don't get the point of this comment: I gave a very clear
: > rationale for not having op in std::multimap, which does not
: > apply to std::map at all.
: operator() is an example of a convenience function which
: the standard added as a member. So is the newly accepted at()
: member for std::map().
Ok. We are talking about a single member function (or two)
provided for *universally* common operations.
The analogy with what we are talking about is quite remote, in
terms of the number of functions, of the complexity (overloads...),
and sufficiency/necessity of incorporating these interfaces.
: > My point remains: ptree is very adequately decoupled from file
: > i/o parsers. Why would you refuse to provide such decoupling
: > for the value conversions ?
: > The current value conversions are far from providing a complete
: > feature set. Some want arrays. Some want a serialization interface.
: > How can you justify carrying a narrow subset of the possible
: > conversion operations into the container itself ??
: It remains to be seen how many user wishes that can be crammed
: into the interface in a reasonable manner.
It is exactly my point: I doubt that a sufficiently complete
and consensual value & object conversion interface can be
completed on time.
So my suggestion is to go ahead with what we have or can do now,
but make it a non-member interface to allow future evolution.
I would expect that more work will follow regarding integration
with boost::serialization, or other means of storing(/retrieving)
objects in a ptree.
-- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk