Denis, please reply to my posting when you reply to me. Pasting part of my post into another thread and replying there is confusing. On 11/29/2010 07:48 AM, Denis Shevchenko wrote:
On 28.11.2010 12:07, Bjørn Roald wrote:
Both program options and serialization provide that to some degree. One thing - what library can do, and another thing - what it is intended. I adhere to the principle "One task - one library". That's why I like to use Boost-libraries. As far as I can see the documentation, Boost.Serialization is certainly not designed for work with a configuration file.
Sure, I agree and I was only referring to the fact that these libraries seems to support more than one external data representation of something that internally is used the same way by the library client code.
I think program options lacks some of the desired flexibility for structure, necessity and validation, but that could possibly be added rather than making an all new library which will be confusing me and others even more. Well, Bjørn, I think it's a question for Vladimir Prus, not for me. :-)
I guess I can ask Vladimir to extend his library, but I did not and do not think I will. I did however ask you why you selected to write a new library rather than proposing an extension to program option. But, you did not paste that part of my post here, so it got lost ;-)
Some time ago I started to use Program_options, but later the possibility of a simple INI-like file was not enough for my programs. I had no purpose to create own solution, so I started looking for a ready free library for configuration file parsing (moreover, it should not be GPL-solution, because it needs me for commercial use). And since I could not find a library corresponding to the principles of simplicity (easy-to-learn and easy-to-use), I decided to create own library under MIT Licence.
Have you considered what it would involve to make program option suitable for your use-cases?
And when the library has been successful (imho), I decided to determine the interests in it there, in Boost.
Good, It is always a good thing with new proposals :-) It may be your proposal is superior to existing libraries - I do not know. However we do have existing libraries in this domain, even if the features vary. I am concerned if Boost keep adding new libraries covering the same ground because someone felt like writing a new one from scratch. In your case it sounds like it is developed it without Boost in mind, and now proposed as seemed to be useful in Boost. I would be less concerned if I saw a good reasoning why your advanced features could or should not be added to Program Options or possibly Property Tree. Failing to understand this, I will assume boost would be better off with enhancements to existing libraries. In that case I will encourage you to contribute to that end. -- Bjørn