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

From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2006-04-24 07:05:00

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.

The introduction of new types bobbles up through your interfaces, and 
you can't convert it to something the normal user knows without copiying 
the data again.

> ....
> : > 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().

> 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.

-Thorsten