Subject: Re: [boost] Library for configuration file parsing
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2010-11-29 15:58:26
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.