Re: [boost] Library for configuration file parsing

Subject: Re: [boost] Library for configuration file parsing
From: Pierre Morcello (pmorcell-cppfrance_at_[hidden])
Date: 2010-12-04 06:23:17

Hello Denis,

>>> - I can not imagine a more simple interface... :-)
If you want to go 'macro', it is certainly possible :

Example 1.1 : 
BOOST_CONFIGURATOR_OPTION( UdpHost , "System::Server::UdpHost" );
BOOST_CONFIGURATOR_OPTION( UdpPort , "System::Server::UdpHost" );

Example 1.2 :
class SomeConfigOptions
{
public:
   int updport;
   Ip updhost;
};

BOOST_CONFIGURATOR_OPTION( 
    SomeConfigOptions, 
    (updport, "System::UdpServer::Port")
    (udphost, "System::UdpServer::Host")
);

then, after parsing all wanted files : 

SomeConfigOptions myConfig;
if( !conf.get(myConfig) )
{
   return error;
}

>>> What do you think about it?

This need real life experience, to check what works and what does not. 

If you have 4 levels in the parse tree, and 250 values, you will have to rewrite many times the types, to declare them and to access them at the same level. After such tests, you can see what works and what does not work.

The user will also have to create lots of types in a namespace with the macro you provide.

I consider that configuration files often reflect the c++ tree of classes.
I doubt you will want to use something like System::UdpServer::Host in the config file, when you only have 1 int in your program. 

I consider it is easier to have a c++ classes tree like :

Example 1.3
struct SoundConfiguration
{
   int option1;
   double option2;
};

// here a macro to declare SoundConfiguration & its attributes...
BOOST_CONFIGURATOR_OPTION( 
    SoundConfiguration, 
    (option1)
    (option2)
);

struct SoundConfigurations
{
   double volume;
   std::vector<SoundConfiguration> sounds;
};

// here a macro to declare SoundConfigurations & its attributes...
BOOST_CONFIGURATOR_OPTION( 
    SoundConfigurations, 
    (volume)
    (sounds)
);

to describe the design of your config file. That way :
a/  you can manipulate compiler-checked information, without creating many types. 
b/ You don't need to repeat the "System::Sound" thing everywhere. 
c/ The 'designation string' could be optional though (ex: ((sounds)("sons")) for a french guy).
d/ If I want the configurator to check the Ip, I create a "Ip myIp" attribute. If I want to check the Ip myself, I create a "std::string myIp" attribute.

I suppose the best 'configurator' system would support both ways.
1/ allow to serialize and deserialise from a human-readable/editable subsection of the file (like a deferred boost.serialize)
2/ allow to use a specific identifier like "System::Udp::Server" to retrieve some other values. Either from the config line or a file.

Boost.PP/boost.spirit/'boost.serialization + boost.xpressiv' offer means to do that easily.

This is at least what comes to me when I read the rationnale you wrote :
"
   1. obtaining options from configuration file,
   2. check correctness (in all senses of this word) of obtained options,
   3. storing options,
   4. issuance of the options values on demand.
"

> <System>
> <UdpServer>
>         Host = 127.0.0.1
>         Port = 100
> </UdpServer>
> </System>

I think writing the tag name twice is harder for humans.

Example 2.1
System
{
  UpdServer
  {
    Host = 127.0.0.1
    Port = 127.0.0.1
  }
}

Or even python-like :
Example 2.2
System
  UpdServer
    Host = 127.0.0.1
    Port = 127.0.0.1

Anyway, this need real life experience, to see what works and what does not(and more tests & examples ! Good that you have already added some in the sandbox!).

Just my point of view.

Best regards,

Pierre Morcello