What is your evaluation of the design? At least, the separator problem should be resolved adequately. What is your evaluation of the implementation? What is your evaluation of the documentation? Good enough What is your evaluation of the potential usefulness of the library? I'm not quite sure but author do not positioning library as registry. I
I am participating at project at which similar system was "invented". And so could provide some suggestions concerning the problem. We start our project from necessity to create windows registry like system for value storage at hierarchical order. Windows approach was quite adequate for our tasks but desire of compatibility makes it impossible to use it. After all win registry interface is archaic and inconvenient. It was our start point. We implemented interface which use node, leaf and attribute approach because of win registry influence. Now I could say that it's looks like mistake. This multilevel model makes interface too complicated without any benefits at reality. So, homogeneous interface of Property Tree Library is much more elegant and simple. I think that one tree implementation is not enough for all kinds of task. The simplest tree of course could be useful for small tasks. But it is not adequate for really big projects. So we create proxy which hides from us details of realization. It gives me opportunity to make unexpected solution for GUI. I don't like GUI programming and try to avoid it if only possible. So I create solution which allows users modify registry at safe manner. Methods of input, validators, access policy and so on prevents user from unsafe input. Safe behavior is based on attributes which stored at the same registry. But it's unsafe and inefficient to store data and visualization attributes at the same place. So proxy which mixed two different proxies for benefits of visualization was created. We decide that symbol '/' is forbidden for using as name. (If you wish to store filename or something which contains '/' you could store it as data not as key. Or if it so necessary to have '/' at name it is possible to use "//" mechanism. Point is not better at all because it's also could be at filename. 'Point looks strange as separator at hierarchical systems. Once more I prefer '/' after win registry semantic. Specifying separator at every function is ugly solution. ) For saving and loading we also use parser mechanism. But we have the basic class for it. It's my favorite trick to use vector of parsers for saving and loading. About name. Property Tree Library is not bad name I think, because being familiar with such approach I immediately understood what it's about. think this road should be leading to registry. At current form it is bonded to quite simple systems.
Did you try to use the library? With what compiler? no Did you have any problems? no How much effort did you put into your evaluation? It was only the comparison with my current solution. But it's taking a long time to. Are you knowledgeable about the problem domain? Yes
The Boost library at my opinion should resolve problem at full scale. It should provide foundation for full variety of different applications from small ini files to multithreaded and even dispersed registries. Alas, at current design library couldn't help me. But bear in mind that I am rather centered on my existing design and that library resolve more simple case I should vote for addition library to boost. Regards, Alexander Belyakov P.S. Well, I want make it clear to prevent misunderstanding that this library is not overlapped by boost.serialization at all but it will be overlapped by boost.registry if some one proposed it. It's clear enough for me that this library shouldn't be viewed as XML reader or any other reader. It's nice library with elegant and simple interface. Author defines property tree as a recursive data structure at another place he wrote it's a container. And it is really so. But REGESTRY is CONCEPTION not data structure. SERIALIZATION is also CONCEPTION. Author makes a lot of work. And he makes it almost ready to transform interface of container to something more interesting - to interface of conception. His library useful and I couldn't ask him to make a lot of work more. But if he wants he could make from it something more powerful. I could provide more information about my project if it's interesting.