SDL_Config: call for comments

[Koshmaar]

Hi guys

Have you noticed that there aren't many open-source libraries for parsing configuration files? I've googled for a while and found only standard WinAPI functions on Windows, and CFL library on Linux distros (but I wasn't searching very long). I thought that it would be nice, if there was open-source, portable C/C++ library for reading/writing configuration files. By "configuration files" I mean .ini files known from Win, ie.

[Foo]

bar = "this is string value"
version = 0.5 // this is float value
integer = 7
fullscreen = false // this is bool
// and this is a comment :-)


I decided to write such library... which will be called SDL_Config (shamelessly plugging into SDL fame :-) ), distributed as GNU GPL, and hosted on Sourceforge. After few days of planning, it became obvious, that there are things which should be discussed with group of potential users. And knowing that there are many advanced "potential users" here on SDL mailing list, who are very experienced in desiging library interface, I dediced to write here. Because it's interface, with what I have problems. 

Questions:

1. Author of TinyXML (which is small library for parsing XML files) decided to give user ability to choose, whether: TinyXML will be using STL containers or self-made versions, and whether to use std::iostreams, or FILE. There are subtle differences between those modes, how they work. First I thought to aspire higher, and went crazy with possible ways my library could be build:

   // It controls what version of function definitions will be compiled - those with or without default values.
   // Not _cplusplus because someone may want to use C version in C++ project
   #define PLAIN_C, C_PLUS_PLUS

   // Defines whether library will be build as static lib, or as DLL
   #define BUILD_STATIC_LIB, BUILD_DLL

   // What string version use in function definitions and internally, when parsing
   #define USE_C_STRINGS, USE_STD_STRINGS, USE_UNICODE_STRINGS

   // Include SDL.h and use typedefs there used, or include separate file, which won’t add dependencies on SDL
   #define USE_SDL_TYPES, USE_OUTSIDE_TYPES

   // Use std::map and iterators, or my own implementation in C
   #define USE_STL, USE_C_CONTAINERS

   // If not defined, functions that operate on bools won’t be compiled? or will be changed to ints? see next point
   #define USE_BOOL

   // Which version of handling files to use
   #define USE_STDIO_FILE, USE_IOSTREAMS

   // How to allocate memory on heap
   #define USE_MALLOC, USE_NEW

Hmmm… quite many, right? Do you think someone would want to use this level of customizeability, knowing that none of them will change external library behavior even a bit, only internal implementation would be different, and interface would change slightly in some cases (strings that would be returned)? Or would it be better just to stick with those options that are available natively in plain C?

2. Bool type - there’s nothing like “bool” in C, and this library is going to be compiled in C. Situation clear - remove functions that operate on bools, right? Not quite, since “bool” exists in C++, so if someone decides to compile this library in C++, he should be able to use bool. Of course, #ifdefs spring to mind, but there’s also issue how to use them, and generally there are two ways:

   1 -Iif _cplusplus isn’t defined, simply don’t compile functions that operate on bools.
   2 - This code will tell you all:

   #ifdef _cplusplus
   #define BOOL bool
   #else
   #define BOOL int
   #endif

Which one do you like more? Is there any third (better) way?

3. Because this library is more or less, just a bunch of plain C functions, and file state is stored in global variables, only one config file can be opened at a time. So, ie. you won’t be able to write to file “aaaa.cfg” and read from “bbbb.cfg” simultaneously - you will have to write all to “aaaa.cfg”, close it, and then open “bbbb.cfg” etc.

Well, at least is how I’m planning it now, but - if it is important to have ability to write/read many files at once - I’ll extend interface (bloating it a little). So, I ask, is it important?

4. This one is easy: will you want to use such library? If there’s no interest, there’s no need to write it, simple.

Thanks in advance for answers!–
Koshmaar
<Of all the things I’'ve lost, I miss my mind the most>
GG: 3928072
http://jnr.sourceforge.net/
www.pongowar.prv.pl

[David_Olofson]

[…]

4. This one is easy: will you want to use such library? If
   there’s no interest, there’s no need to write it, simple.

Well, I guess I could use something like that, since there is
something like it in Kobo Deluxe… BTW, it also handles command line
switches (each “option” maps to both interfaces), which has turned
out to be pretty handy. Development versions also autogenerate the
command line help from the same data. I guess there’s more stuff that
could be automated like this, but I think it’s doing pretty well
already, covering those three things.

I’ve been thinking about turning it into a separate library or
something, but you know the deal; “Any year now…”

Another thought: Why would this have to be SDL specific…?

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 06 July 2005 23.17, Koshmaar wrote:

[Rainer_Deyke]

Koshmaar wrote:

I decided to write such library… which will be called SDL_Config
(shamelessly plugging into SDL fame ), distributed as GNU GPL,
and hosted on Sourceforge.

Please either drop the SDL_ prefix, or use the less restrictive LGPL
license. AFAIK all other SDL_* libraries use the LGPL, so it would be
confusing if SDL_Config used a different library.

1. Author of TinyXML (which is small library for parsing XML files)
   decided to give user ability to choose, whether: TinyXML will be
   using STL containers or self-made versions, and whether to use
   std::iostreams, or FILE. There are subtle differences between those
   modes, how they work. First I thought to aspire higher, and went
   crazy with possible ways my library could be build:

// It controls what version of function definitions will be compiled

• those with or without default values. // Not _cplusplus because
  someone may want to use C version in C++ project #define PLAIN_C,
  C_PLUS_PLUS

To cooperate with other libraries, please use a prefix on all
preprocessor symbols your library uses.

If you want separate interfaces for C and C++, a better approach would
be to write the C++ interface as a layer on top of the C library. Or
just make it a C++ library.

// Defines whether library will be build as static lib, or as DLL
#define BUILD_STATIC_LIB, BUILD_DLL

// What string version use in function definitions and internally,
when parsing #define USE_C_STRINGS, USE_STD_STRINGS,
USE_UNICODE_STRINGS

Which unicode strings would that be? std::wstring in UTF16?
std::string in UTF8? Custom unicode string class? Other?

// Include SDL.h and use typedefs there used, or include separate
file, which won’t add dependencies on SDL #define USE_SDL_TYPES,
USE_OUTSIDE_TYPES

// Use std::map and iterators, or my own implementation in C #define
USE_STL, USE_C_CONTAINERS

// If not defined, functions that operate on bools won’t be compiled?
or will be changed to ints? see next point #define USE_BOOL

// Which version of handling files to use #define USE_STDIO_FILE,
USE_IOSTREAMS

// How to allocate memory on heap #define USE_MALLOC, USE_NEW

Hmmm… quite many, right? Do you think someone would want to use
this level of customizeability, knowing that none of them will change
external library behavior even a bit, only internal implementation
would be different, and interface would change slightly in some cases
(strings that would be returned)? Or would it be better just to stick
with those options that are available natively in plain C?

Stick to customization options that actually matter.

2. Bool type - there’s nothing like “bool” in C, and this library is
   going to be compiled in C. Situation clear - remove functions that
   operate on bools, right? Not quite, since “bool” exists in C++, so if
   someone decides to compile this library in C++, he should be able to
   use bool. Of course, #ifdefs spring to mind, but there’s also issue
   how to use them, and generally there are two ways:

1 -Iif _cplusplus isn’t defined, simply don’t compile functions that
operate on bools. 2 - This code will tell you all:

#ifdef _cplusplus #define BOOL bool #else #define BOOL int #endif

Which one do you like more? Is there any third (better) way?

Just use ‘int’ in a C library.

3. Because this library is more or less, just a bunch of plain C
   functions, and file state is stored in global variables, only one
   config file can be opened at a time. So, ie. you won’t be able to
   write to file “aaaa.cfg” and read from “bbbb.cfg” simultaneously -
   you will have to write all to “aaaa.cfg”, close it, and then open
   "bbbb.cfg" etc.

Well, at least is how I’m planning it now, but - if it is important
to have ability to write/read many files at once - I’ll extend
interface (bloating it a little). So, I ask, is it important?

I don’t like global state, so I would prefer the ability to open
multiple configuration files, even if I never use it.

4. This one is easy: will you want to use such library? If
   there’s no interest, there’s no need to write it, simple.

Not if it’s GPL. Maybe if it’s LGPL. I have no own code to handle
configuration files, so I would only switch if there is a compelling
reason to switch to your library.

BTW, one cool feature would be to automatically store configuration
files in the correct place on various platforms.
~/.application/filename for Linux, ~/Library/Preferences/filename on OS
X, ~/Application Data/application/filename on Windows, or something like
that. Of course not everyone will agree on what the correct place to
store preferences on each platform is.–
Rainer Deyke - rainerd at eldwood.com - http://eldwood.com

[David_Olofson]

[…]

I don’t like global state, so I would prefer the ability to open
multiple configuration files, even if I never use it.

Have to agree on that.

4. This one is easy: will you want to use such library? If
   there’s no interest, there’s no need to write it, simple.

Not if it’s GPL. Maybe if it’s LGPL.

Good point. ++LGPL.votes;

I do believe that software in general should be Free, but given the
nature of games (the vast majority of end users hardly seem to know
what “source code” is), it’s futile to try to force authors to
release all of their code. The only result is that they ignore your
library - and you miss out on lots of free testing and feedback.

BTW, one cool feature would be to automatically store configuration
files in the correct place on various platforms.
~/.application/filename for Linux, ~/Library/Preferences/filename on
OS X, ~/Application Data/application/filename on Windows, or
something like that.

That could avoid quite a bit of frustration, especially for FOSS
developers that can’t test on all platforms they “support”…

Of course not everyone will agree on what the
correct place to store preferences on each platform is.

Tell me about it… >:-/

In the future, I’m simply going to ignore all Linux distros and stick
with the FHS.

Or maybe not… What’s this “games” nonsense all about!? Games,
simulators and whatnot are applications, period. Or do we have
special places for office applications, musical applications, CAD
software and whatnot?

Guess there is simply no single correct way of dealing with this…
Just pick one.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Thursday 07 July 2005 01.09, Rainer Deyke wrote:

[icculus]

Please either drop the SDL_ prefix, or use the less restrictive LGPL
license. AFAIK all other SDL_* libraries use the LGPL, so it would be
confusing if SDL_Config used a different library.

Actually, just drop the “SDL_” prefix, period, unless it has something
to do with SDL. I think that’s only fair.

–ryan.

[Jean-Gregoire.FOULON]

Hello,

Have you noticed that there aren’t many open-source libraries for parsing configuration files? I’ve googled for a while and found only standard WinAPI
functions on Windows, and CFL library on Linux distros (but I wasn’t searching very long). I thought that it would be nice, if there was open-source,
portable C/C++ library for reading/writing configuration files. By “configuration files” I mean .ini files known from Win, ie.

I used a library that read the ini files, it looks portable (windows and unix at least) and has a non restrictive licence :

http://ndevilla.free.fr/iniparser/

it is not C++, but you could just make a C++ wrapper around it, it would be faster that rewriting a new lib from scratch.

Jean-Gr?goire

[Anders_F_Bjorklund]

Koshmaar wrote:

Have you noticed that there aren’t many open-source libraries for
parsing configuration files? I’ve googled for a while and found only
standard WinAPI functions on Windows, and CFL library on Linux
distros (but I wasn’t searching very long).

Yes, I did notice - and most of the available ones use XML or C++…
(which made them all way too heavy for my intended use that I had)

I thought that it would
be nice, if there was open-source, portable C/C++ library for
reading/writing configuration files. By “configuration files” I mean
.ini files known from Win, ie.

Funny, as I had the same exact thought with our “SpriteWorld X”…
I wanted something that was plain ANSI C, and under a BSD-ish license.

I decided to write such library… which will be called SDL_Config
(shamelessly plugging into SDL fame ), distributed as GNU GPL,
and hosted on Sourceforge. After few days of planning, it became
obvious, that there are things which should be discussed with group
of potential users.

I don’t think such a library would require a few days of planning ?
(then again, maybe yours is more advanced but mine took a few hours)

1. Author of TinyXML (which is small library for parsing XML files)
   decided to give user ability to choose, whether: TinyXML will be
   using STL containers or self-made versions, and whether to use
   std::iostreams, or FILE.

Too many options. Just use SDL_rwops ?

2. Bool type - there’s nothing like “bool” in C, and this library is
   going to be compiled in C.
   […]
   Which one do you like more? Is there any third (better) way?

Yes, just use the SDL_bool type ? (int)

3. Because this library is more or less, just a bunch of plain C
   functions, and file state is stored in global variables, only one
   config file can be opened at a time. So, ie. you won’t be able to
   write to file “aaaa.cfg” and read from “bbbb.cfg” simultaneously -
   you will have to write all to “aaaa.cfg”, close it, and then open
   "bbbb.cfg" etc.

Global variables suck, so use a struct… (even a hash is overkill)

4. This one is easy: will you want to use such library? If
   there’s no interest, there’s no need to write it, simple.

If you want to use ours, it’s available under zlib/libpng license at:
http://cvs.sourceforge.net/viewcvs.py/spriteworldx/
spriteworldx/Utils/SWProperties.h?view=auto

It has some custom “SWError” and “SWBoolean” compatibility types,
but you can change those for “int” if using it somewhere else…
Also, the implementation is not exactly robust but seems to work ?

–anders

PS.
For the project home page, look here:
http://spriteworldx.sourceforge.net/
(there’s also some standalone SDL/GL
stuff in the “BlitKernel” subproject)

[Koshmaar]

Hi David

Well, I guess I could use something like that, since there is
something like it in Kobo Deluxe…

Great

BTW, it also handles command line
switches (each “option” maps to both interfaces), which has turned
out to be pretty handy. Development versions also autogenerate the
command line help from the same data. I guess there’s more stuff that
could be automated like this, but I think it’s doing pretty well
already, covering those three things.

Heh, that’s a little to much for my library.

I’ve been thinking about turning it into a separate library or
something, but you know the deal; “Any year now…”

Hmmm, my english-skills still aren’t good enough to undestand all english proverbs

Another thought: Why would this have to be SDL specific…?

//David Olofson - Programmer, Composer, Open Source Advocate

Do you mean “it could only be compiled with SDL”? I’m still thinking about such a system, where, if you want, you can compile with SDL, but if you don’t want to add SDL dependency (ie. because you’re using Allegro), then by changing one #define, library will be built with another set of types and functions, that are used inside it. Ie:

#ifdef USE_SDL
typedef cfg_uint32 Uint32;
#else
typedef cfg_uint32 unsigned int;
#endif

cfg_uint32 CFG_OpenFile(const char * filename);

Does it make any sense to do it in this way?

Koshmaar

[Koshmaar]

Please either drop the SDL_ prefix, or use the less restrictive LGPL
license. AFAIK all other SDL_* libraries use the LGPL, so it would be
confusing if SDL_Config used a different library.

Ups, sorry everyone, of_course it ought to be written “LGPL”, not “GPL”. I see it made a lot of confusion, so sorry once again (stupid typos :-/).

// It controls what version of function definitions will be compiled

• those with or without default values. // Not _cplusplus because
  someone may want to use C version in C++ project #define PLAIN_C,
  C_PLUS_PLUS

To cooperate with other libraries, please use a prefix on all
preprocessor symbols your library uses.

Ok, good point.

If you want separate interfaces for C and C++,

Honestly, the last thing I would want, it would be seperate interfaces for C and C++. There are just some syntactic sugars in C++, that would be good to support, if user is compiling in C++. If he’s not, then sorry.

a better approach would
be to write the C++ interface as a layer on top of the C library. Or
just make it a C++ library.

That’s interesting - probably eventually I’ll write wrapper class around this library, so that user could parse config files in OOP way, ie.

CFG_File config("settings.cfg"); // opens and parses file "settings.cfg"

config.OpenGroup("Video"); // selects "Video" group

bool fullscreen = config.ReadBool("fullscreen", true); // second argument is default value, which will be returned when such entry wasn't found

// What string version use in function definitions and internally,
when parsing #define USE_C_STRINGS, USE_STD_STRINGS,
USE_UNICODE_STRINGS

Which unicode strings would that be? std::wstring in UTF16?
std::string in UTF8? Custom unicode string class? Other?

That’s difficult question - I don’t have any real experience in coding with Unicode, but:

1. Coding my self unicode string class would be nothing more than forcing open door, similiar to rewritting STL, and I’m not even feeling up to it, nor I have will to do it.

2. Probably it will look like this:

   If you’re programming in C, then library will be using standard C functions for operating on const chars *.
   If you’re programming in C++, then you will be given a choice:
   - you use std::string with standard ASCII
   - you use std::wstring with UTF16
   - you may also use const chars *, if you really want to

Hmmm… quite many, right? Do you think someone would want to use
this level of customizeability, knowing that none of them will change
external library behavior even a bit, only internal implementation
would be different, and interface would change slightly in some cases
(strings that would be returned)? Or would it be better just to stick
with those options that are available natively in plain C?

Stick to customization options that actually matter.

Ok, good advice.

1 -Iif _cplusplus isn’t defined, simply don’t compile functions that
operate on bools. 2 - This code will tell you all:

#ifdef _cplusplus #define BOOL bool #else #define BOOL int #endif

Which one do you like more? Is there any third (better) way?

Just use ‘int’ in a C library.

That was also my favourite

I don’t like global state, so I would prefer the ability to open
multiple configuration files, even if I never use it.

Hmmm, it looks like other people also think like that. The reason I was against it, is that it would bloat library a little, and made using it less easy, ie. you would have to pass to nearly every function one struct more, which would identify file you are working on.

4. This one is easy: will you want to use such library? If
   there’s no interest, there’s no need to write it, simple.

Not if it’s GPL. Maybe if it’s LGPL. I have no own code to handle
configuration files, so I would only switch if there is a compelling
reason to switch to your library.

Yes, I say once again: that GPL was my (stupid) mistake.
Well, anyway, that’s great - there’s already one person who might use it!

BTW, one cool feature would be to automatically store configuration
files in the correct place on various platforms.
~/.application/filename for Linux, ~/Library/Preferences/filename on OS
X, ~/Application Data/application/filename on Windows, or something like
that. Of course not everyone will agree on what the correct place to
store preferences on each platform is.

–
Rainer Deyke - rainerd at eldwood.com - http://eldwood.com

Hmmm, good idea, but there are 3 reasons why it probably won’t be added:

1. This library was meant to be rather low-level, so if you want such higher-level behaviour - you should write it by yourself.
2. Generally on all platforms, for flexibility’s and clearness sake, when you say “open file abcd.cfg”, it means: open file abcd.cfg in respect to current working directory.
3. I have no experience in progamming anything on platforms other than win32

Anyway, thx a lot for comments!

Koshmaar

[Koshmaar]

Please either drop the SDL_ prefix, or use the less restrictive LGPL
license. AFAIK all other SDL_* libraries use the LGPL, so it would be
confusing if SDL_Config used a different library.

Actually, just drop the “SDL_” prefix, period, unless it has something
to do with SDL. I think that’s only fair.

–ryan.

I’m going to use SDL_GetError() and SDL_SetError() just like SDL_TTF and SDL_Image do. Apart from that, I will be also using SDL types (Uint32 etc.) and generally use interface (ie. naming standards) very similiar to aforementioned libraries. So, IMHO it has sth to do with SDL

Btw, another reason I want to use SDL_Config, is because I couldn’t come up with other cool name for such configuration library :-/

Koshmaar

[Koshmaar]

Have you noticed that there aren’t many open-source libraries for parsing configuration files? I’ve googled for a while and found only standard WinAPI
functions on Windows, and CFL library on Linux distros (but I wasn’t searching very long). I thought that it would be nice, if there was open-source,
portable C/C++ library for reading/writing configuration files. By “configuration files” I mean .ini files known from Win, ie.

I used a library that read the ini files, it looks portable (windows and unix at least) and has a non restrictive licence :

http://ndevilla.free.fr/iniparser/

it is not C++, but you could just make a C++ wrapper around it, it would be faster that rewriting a new lib from scratch.

Jean-Gr?goire

It’s not entirely from scratch, I have already coded such cfg library in C++ with OPP, but it was just too much connected to my own engine, so others couldn’t use it.

Btw, thanks for link, I’ve noticed interesting thing about library you mentioned: hierarchical ini files. Let me quote:

" ini files are nice to present informations to the user in a readable format, but lack a very useful feature: the possibility of organizing data in a hierarchical (tree-like) fashion. The following convention can be used to make ini files obtain this second dimension:

A section depends on another section if it contains its name as a prefix, separated by slashes (/). For example: we have 2 main sections in the ini file. The first one is called Pizza and has two child subsections called Cheese and Ham. The second main section in the ini file is called Wine and has two child subsections called Year and Grape. As a tree, this could appear as:
|
±- Pizza
| ±- Cheese
| ±- Ham
±- Wine
±-- Year
±-- Grape

In an ini file, that would be converted to:
[Pizza]

[Pizza/Cheese]
Name   = Gorgonzola ;
Origin = Italy ;

[Pizza/Ham]
Name   = Parma ;
Origin = Italy ;

[Wine]

[Wine/Year]
Value = 1998 ;

[Wine/Grape]
Name   = Cabernet Sauvignon ;
Origin = Chile ;

This proposal is actually more related to the way people write ini files, more than the parser presented here. But it is certainly a useful way of making tree-like data declarations without going through painful formats like XML.
Accessing the above tree would give something like (error checking removed for clarity sake):

dictionary * d ;

d = iniparser_load("example.ini");

printf("cheese name is %s\n", iniparser_getstr(d, "pizza/cheese:name"));
printf("grape name is %s\n",  iniparser_getstr(d, "wine/grape:name"));

iniparser_freedict(d);

The whole ini file above is represented in the dictionary as the following list of pairs:
key value

"pizza"                         NULL
"pizza/cheese"                  NULL
"pizza/cheese:name"             "Gorgonzola"
"pizza/cheese:origin"           "Italy"
"pizza/ham"                     NULL
"pizza/ham:name"                "Parma"
"pizza/ham:origin"              "Italy"
"wine"                          NULL
"wine/year"                     NULL
"wine/year:value"               "1998"
"wine/grape"                    NULL
"wine/grape:name"               "Cabernet Sauvignon"
"wine/grape:origin"             "Chile"

"

That looks quite interesting, but, seeing no difference in how it’s used in code, IMHO it’s nothing more than just extending section names with additional prefix, and then adding that prefix in code. And, if it’s like that, than such system could be easily used in other ini libraries - just add prefix…
Or am I wrong and don’t see obvious benefits?

Btw, you reminded me of one more thing: multiple values per key. Normally, each entry in cfg file looks like this:

<entry> ::== <key_name> = <key_value>

while with multiple values per key:

<entry> ::== <key_name> = <key_value> [, <key_value>]

It could be useful ie. in storing list of maps for multiplayer map rotator:

[Maps]

    ListOfMaps = "map1.lev", "map2.lev", "map3.lev"

Of course, such addition would add a little bloat factor to library (ie. need to store list of values instead of single value; separate set of functions to work with multiple values), but if it’s needed, then it’s good to know about it and plan adding it from beggininng.

Koshmaar

[Koshmaar]

I don’t think such a library would require a few days of planning ?
(then again, maybe yours is more advanced but mine took a few hours)

Maybe not more advanced, but for sure it will be a lot bigger, and a lot harder to test all those versions - its much better to plan extensively before writing

1. Author of TinyXML (which is small library for parsing XML files)
   decided to give user ability to choose, whether: TinyXML will be
   using STL containers or self-made versions, and whether to use
   std::iostreams, or FILE.

Too many options. Just use SDL_rwops ?

Hmmm, I intended to add few functions for specifying file you wish to parse by SDL_Rwops structures, but never thought that it could completely replace other I/O methods.

But, there’s another problem - adding dependency on SDL_Rwops would make it impossible to use this library by people, who aren’t using SDL, so in theory, I should maintain 3 paths: FILE, std::iostreams and SDL_Rwops :-/

…

But you know what, I’m getting more and more ready to go “SDL dependency is required” path, since a lot of people are using SDL nowadays, so it woulnd’t be very big problem, and would certainly make maintaining of lib MUCH easier.

Which one do you like more? Is there any third (better) way?

Yes, just use the SDL_bool type ? (int)

Ok, I’ll do it like this then.

3. Because this library is more or less, just a bunch of plain C
   functions, and file state is stored in global variables, only one
   config file can be opened at a time. So, ie. you won’t be able to
   write to file “aaaa.cfg” and read from “bbbb.cfg” simultaneously -
   you will have to write all to “aaaa.cfg”, close it, and then open
   "bbbb.cfg" etc.

Global variables suck, so use a struct… (even a hash is overkill)

Hmmm, I will have to think about it more…

4. This one is easy: will you want to use such library? If
   there’s no interest, there’s no need to write it, simple.

If you want to use ours, it’s available under zlib/libpng license at:
http://cvs.sourceforge.net/viewcvs.py/spriteworldx/
spriteworldx/Utils/SWProperties.h?view=auto

It has some custom “SWError” and “SWBoolean” compatibility types,
but you can change those for “int” if using it somewhere else…
Also, the implementation is not exactly robust but seems to work ?

–anders

Thx for link, I won’t use it, but I will definitely take a look at your implementation

Koshmaar

P.S. Thanks a lot for all comments so far! You really helped me

[SkunkGuru]

BTW, one cool feature would be to automatically store configuration
files in the correct place on various platforms.

Hmmm, good idea, but there are 3 reasons why it probably won’t be added:

if you want to add this, you could look and integrate with this:

http://www.maccormack.net/~djm/fnkdat/--
SkunkGuru.

[SkunkGuru]

(haven’t seen this message on the list, I try again)

BTW, one cool feature would be to automatically store configuration
files in the correct place on various platforms.

Hmmm, good idea, but there are 3 reasons why it probably won’t be added:

if you want to add this, you could look and integrate with this:

http://www.maccormack.net/~djm/fnkdat/--
SkunkGuru.

[Koshmaar]

(haven’t seen this message on the list, I try again)

BTW, one cool feature would be to automatically store configuration
files in the correct place on various platforms.

Hmmm, good idea, but there are 3 reasons why it probably won’t be added:

if you want to add this, you could look and integrate with this:

http://www.maccormack.net/~djm/fnkdat/

–
SkunkGuru.

Thx for memory, but I’ve got it the first time

And thx for the link, but I still believe that such behaviour should be written by user.
Also, I don’t want to add dependency on another lib - SDL is enough.

Koshmaar