"Thorsten Ottosen" <thorsten.ottosen@dezide.com> wrote in message news:444CB0DC.3040501@dezide.com... : Ivan Vecerina wrote: : > "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. : : 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