/** @page recipes Recipes

    Here, we'll give solution for some desires which seem common.

    @section recipe_parameter_validation How to check for correct option value types and assign them?

    There's the boost::program_options::parameter function. It
    returns a object, which, if passed as the second parameter
    to boost::program_options::option_description constructor,
    establishes correct validation routine. A simple example
    is
    @code
    options_description desc;
    desc.add_options()
    ("foo", parameter<int>("arg"), "obscure option")
    ;
    @endcode

    If you pass an address of <tt>int</tt> variable as the second
    parameter of the <tt>parameter</tt> function, that variable will
    be assigned the options's value.

    @sa @ref variables_map

    @section recipe_lazy What if I don't want to declare any options?

    I'm not sure this is good idea. In particular, mistyped options
    will be silently ignored, leading to possible user surprises. 
    Futher, the boost::program_options::cmdline class was specially
    designed to be very lightweight. 

    Anyway, there's a version of the parse_command_line function
    which does not take an options_description instance. Also, the
    cmdline class ctor accepts an 'allow_unregistered' parameter. 
    In both cases, all options will be allowed, and treated as if
    they have optional parameter.

    Note that with the default style, 
    @verbatim
    --foo bar
    @endverbatim
    will be taken as option "foo" with value "bar", which is
    probably not correct. You should disable option parameter in
    the next token to avoid problems.

    @sa boost::program_options::cmdline

    @section recipe_multiple_modules I have several separate modules which must controlled by options. What am I to do?

    There are several solutions. 

    @subsection sb1 Everything's global

    You can create a single instance of the <tt>options_description</tt> class
    somewhere near <tt>main</tt>. All the modules will export their own
    options using other <tt>options_description</tt> instances which can
    be added to the main one. After that, you'd parse command line and 
    config files. The parsing results will be stored in one variables_map,
    which will be passed to all modules, which can work with their own 
    options.

    @subsection sb2 Private option data

    Assume one of the modules does not like to see irrelevant options.
    For example, it outputs a configuration file for other program, and
    irrelevant options will confuse that program. 

    It's possible to give the module only the options that it has
    registered. First, the module provides an options_description instance
    which is added to the global one. Second the command line is parsed
    to produce an options_and_arguments instance. Lastly, the <tt>store</tt>
    function is called. If passed the options_description instance previously
    returned by the module, it will store only options specified in that
    instance. 
    @sa @ref multiple_modules
    

    @subsection sb3 Unique option names

    The most general solution would be to give unique names to options
    for different modules. One module will declare option "module1.server",
    and another would declare "module2.internal_checks". Of course, there
    can be global options like "verbosity", declared by <tt>main</tt> and
    used by all modules.

    This solution avoids all possible name clashes between modules. On
    the other hand, longer option names can be less user-friendly. This
    problem can be alleviated if module prefix is used only for less 
    common option, needed for fine-tuning.

*/