config file interface

[valis]

As a part of my current project I'm writing a configuration file interface.

Originally I had thought it would be easier for people to just use a parser generator, but with something as simple as a config file it's easier to simply call a few functions sacrificing speed for ease (and speed) of implementation. Currently only three functions need to be called for the simplest method, init, parse, and shutdown.
I currently have some level of complexity (like expressions) but I still want to keep it largely simplistic because it's not a scripting language.

My first question is: if you were using a config file api what kinds of functions would you like to see in it? Are extra things like structure definition useless bulk compared to the simple ini [section] style?

And secondly: For parsing large sections at once (like chunks of vars), do you like the idea of accessing information with an associative array type method; or would something else be better?

Thanks ahead.

[Wraithan]

Depending on what I need I either like a small interface that can do simple [section] key=value style. Or sometimes I want stuff that does a lot more complicated stuff.

[jafet]

If you were using C++, you can create associative arrays using std::map and save yourself the trouble. You could imitate it and create a char[]-indexed binary tree (more work to implement) or a linked list (slower code).

Flexibility and simplicity should be key. As for me, I would have this done:

[names]
#this is a comment
Doe=John
Age=34
Famous quote=Multi-line\
stuff

This variable is not assigned a value...
While this is assigned an empty string=

[math]
1 + 2=3
1\=\=2=false #"1==2" = false
1!\=2=true #"1!=2" = true

But just so you know, if I wanted more complex stuff like structures and attributes I'd just dump ini files and go XML.

[valis]

This is my disclaimer for a long and ugly post, also I'm obviously not trying to make a replacement for xml, just an alternative I can use and others if I decide my stuff isn't too ........ty to put up somewhere.

The xml thing gave me a very good idea. I've always hated xml, I find it cluttered and difficult to read, I slapped together something very similar to xml in idea but very different in syntax.
Structural Component Descriptions will define (obviously) the structure of configuration files much like dtd's do in xml.
I hacked together what that part of the language will look like, I would appreciate input from you all (syntactic and functional):

SDC ::= header SCD_construct+
header ::= SCD_global_descriptor

SCD_global_descriptor ::= '[+scd]' ('{' version scd_version scd_name '}' | version scd_version scd_name)
version ::= num '.' num
SCD_construct ::= cname (enum_construct | structure_construct)

enum_construct ::= '=' edescriptor ('|' edescriptor)*
edescriptor ::= [_A-Za-z][_A-Za-z0-9]*

structure_construct ::= '{' (presence_modifier? type_check? fieldname ('=' fvdefault)? fterminator)+ '}'
presence_modifier ::= '?' | '+' | '*' | '['num '-' num? ']'
type_check ::= native or defined type names separated by commas
fieldname ::= [_A-Za-z][_A-Za-z0-9]*
fvdefault ::= value which is valid for this type (if a typecheck exists)
fterminator ::= ',' | ';' | '\n' | '\r'

type_check makes sure that the type used in the configuration file matches one of the types specified, otherwise any type is valid. Native types will be integral, floating point, and string. presence_modifier will state how many times the field can or must exist in the configuration file.
I also have the binary form layed out but this is already a fat post.

And finally an example scd

[+scd]
version=0.1
scd_name="sample scd"
scd_version=1

aWindow { ?integral x = 100, ?integral y = 100;
*string child
width; float height
[19-]something_else}

apart = PART_ONE | PART_TWO | PART_SIX

If an aWindow appears in the configuration file then it may or may not define x and y, it can define zero or more instances of child, must define width and height, and 19 or more instances of something_else. if an apart appears then it's value can only be PART_ONE PART_TWO or PART_SIX.

I haven't layed out the configuration files yet but I plan on making them pretty flexible, not just C89 or C99 structure definitions in any case.

Please--even if you wouldn't use something like this, give me input so I can make it easier, cleaner, and better. It's a first rough draft and I would like to produce something reuseable.