Re: [boost] [property_tree review] Making the interface leaner, concretely...

From: Ivan Vecerina (ivec_at_[hidden])
Date: 2006-04-24 07:52:11

"Thorsten Ottosen" <thorsten.ottosen_at_[hidden]> wrote in message 
news:444CB0DC.3040501_at_dezide.com...
: 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 
dataor
: > : 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.

Ivan
-- 
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form