"Thorsten Ottosen" <thorsten.ottosen@dezide.com> wrote in message news:444BDD01.5030601@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