Michel said:
ACtually, there are many pitfalls:
(1) What of duplicate sections?
I treated the second (and subsequent) duplicate section as an
(intended) continuation of the first.
(2) What of duplicate keys?
I allowed duplicate keys; and if the value associated with the
duplicate didn't duplicate an existing entry's in the current
section, created a new KVP entry for the current section. If the
application didn't like duplicate keys, /it/ could complain,
abort, etc.
(3) What of space before/after, the key/the value?
I strip leading and trailing spaces from section names, keys, and
values. When multiple spaces are found within section names and
keys, they are reduced to single spaces. Multiple spaces within
values are retained.
(4) Is order significant? Should it be maintained?
I maintained the order of /first instance/ of sections and KVPs
within each section. KVPs and text entries were kept in separate
lists. (BTW, this was my rationale for using linked lists.)
(5) What of KVPs outside a section? A proposal was made by Morris
(below), but it is not the only possible one, one could ignore them with
or without warning.
It struck me as perilous to silently discard configuration data;
and I preferred to have the application do any complaining. This
was my rationale for the "ghost" [Global] section.
(6) What of lines not conforming to K=V? Here again a proposal is made
by Morris, but is it the best? Maximal compatibility with MS-Windows
could be a design goal.
Well, I'd actually /wanted/ section-specific (multi-line) text,
so that's what I built in. Given that it supported a requirement
rather exactly, it /was/ the best solution. (But YMMV.
Given that I'm pretty much a POSIX bigot, I felt completely free
to improve on MS-anything (and they make it /so/ easy to do!)
I would rather use B-tree of sections, with B-tree of key/value pairs,
plus hased keys for fast comparisons.
Ok by me. My .ini files were relatively small (under 24k); and I
wasn't too worried about one-time initialization overhead. Again,
YMMV.
Stateful, yes. Yuck? Beauty is in the eye of the beholder. The
code was quick, simple, and reliable. All told, the package took
less than two hours to design, code, and debug -- and I was on to
the actual application code. Production of a reliable major
application delivered considerably under budget and much ahead of
schedule made a very happy client, who found it beautiful! (BTW,
they particularly liked the extreme flexibility that the various
configuration files provided.)