Re: how to parse INI files ?
From: Michel Bardiaux (mbardiaux_at_peaktime.be)
Date: 10/31/03
- Next message: Irrwahn Grausewitz: "Re: Named parameters"
- Previous message: Andreas Kahari: "Re: A C-Program Question"
- In reply to: Morris Dovey: "Re: how to parse INI files ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 31 Oct 2003 11:19:32 +0100
Morris Dovey wrote:
> Michel Bardiaux wrote:
>
>> Morris Dovey wrote:
>
>
>>> There are three aspects to this problem:
>>>
>>> 1. Input and parse each line
>>> 2. Save the information in some usable form
>>> 3. Access the information as needed
>>>
>>> (1) isn't too difficult
>>
>
>> 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. 8-)
>
> 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 was taking exception to the idea that parsing was "relatively easy"; I
see you've pretty much covered all the bases. Even though I disagree
with most of your design decisions - I disallow duplicate sections,
duplicate keys, out-of-section keys, and order is neither relevant nor
maintained; and MSW compatibility *was* an important point, because we
do have customers who want MSW applications. The important issue is not
what choices are made, but that they are made at all and fully documented.
>
>>> (2) is easily handled by building a linked list of sections;
>>> and by attaching a list of key/value structures to each
>>> section.
>>
>>
>> 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.
We have strongly optimized access to the .INI; then it becomes practical
to look them up when needed, rather than writing all the data structures
needed to keep the information in-core.
>
>>> (3) is most easily handled by writing a set of functions
>>> like:
>>>
>>> find_section()
>>> next_section()
>>> find_key()
>>> next_key()
>>
>
>> A stateful API. Yuck.
>
>
> Stateful, yes. Yuck? Beauty is in the eye of the beholder. The code was
> quick, simple, and reliable.
A POSIX bigot using an API modelled on FindFirst/FindNext? :-)
> 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.)
-- Michel Bardiaux Peaktime Belgium S.A. Bd. du Souverain, 191 B-1160 Bruxelles Tel : +32 2 790.29.41
- Next message: Irrwahn Grausewitz: "Re: Named parameters"
- Previous message: Andreas Kahari: "Re: A C-Program Question"
- In reply to: Morris Dovey: "Re: how to parse INI files ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
