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

From: Ivan Vecerina (ivec_at_[hidden])
Date: 2006-04-24 02:59:48

"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.
Is the performance of those libraries measurably hit?
If so, maybe you want a pod_vector, which will also benefit
from relying on realloc.  No big deal.

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

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

If the only justification is the desire to provide member
functions because "it's the better java way", "some editors
support it better", or "it will be easier for novices",
then please offer a separate class that stores a reference
to a ptree container:
 class ptree_valueio {
    ...
    there you can store a default path separator,
    a default locale, etc etc etc -- as some requested.
    ...
   public:
     ptree&  tree();
     ... all the current input/output functions ...
 };

If this is not worth the effort, then provide a non-member interface.

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