Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-05-14 00:50:58

Preston A. Elder wrote:

> The INI file parser module of program_options needs to be changed. For
> some reason, the comment delimiter has been changed from ';' to '#'. The
> bigger problem is this has been taken beyond the first character of the
> line and there is no escaping ability!
> The more common INI file comment behavior is:
> '#' is a comment ONLY if it is the first character of the line
> ';' is a comment from that point of the line on, unless preceeded by a '\'
> (or more accurately, an odd number of '\' characters, since you could
> theoretically do \\\;, to translate to \; when made a string).

It's the first time I hear about ';' being used as comment delimiter. Can
you point me out to some docs which document INI format as above? Note also
that I never say that format of config files is exactly as used by
Windows .ini files.

> I have written my own INI parser for my own purposes, but it is not
> associated with program_options, which makes its usefulness in that
> context limited (without a lot of extra coding, etc).
> You can view the source here:

I'll take a look

> My own implementation does differ from the standard INI file parsing
> convention in allowing line continuation, ie.
> Allowing:
> my_option = some text \
> some more text
> And it is interpreted as 'some text some more text'.

I intend to add this functionality too.

> One big selling point of my implementation is that it uses boost::spirit
> (the lexical parser) to do the parsing - so the logic for parsing is
> encoded in the lexical parsing language, not in code. Theoretically, this
> means you should be able to use my implementation directly, and adapt the
> code from IniFile::Load() that uses it for program_options relatively
> easily, and not have to worry about the parsing logic itself.

Sorry, this is not a selling point, it's a drawback. For a simple task like
parsing ini files Spirit is a overkill. To be specific:
1. Spirit does not work with borland, while program_options does. I don't
want to do as serialization do, and require older Spirit for borland --
that's maintenance nightlmare.
2. IIRC, there were reports of Spirit problems on darwin and on VC 8.0, and
I don't want to be affected by those.

> Otherwise (if you don't want to use a lexical-parser based implementation,
> or my version specifically), could we please stick to the standards,

I'd be happy to stick to standards provided you give an URL to those
standards ;-)

- Volodya

Boost list run by bdawes at, gregod at, cpdaniel at, john at