using ini files

First of all, Windows INI-files are obsolete since Win32. You should actually store this information in the registry. But I can imagine there are things you would rather keep in an organized file and the INI format is sometimes suitable.

This section on MSDN lists the functions to read/write to the registry as well as to INI files (see for example WritePrivateProfileSection).

Illco

Be aware that the built-in INI functions in windows are horrbily horrbily slow even for I/O functions because every single calls has to parse the file again. It'd be better to parse the file yourself, which is trivial to do using std:: string, fstream, and map.

If you decide to use the registry instead, make absolutely sure you provide an uninstaller tool that completely undoes everything your program did to the registry. I _HATE_ the way most uninstallers don't clean up the crap their installers leave around in the registry.

thanks, anon, for the extensive code.

I may well parse the file into a map as Ex suggests.

Thanks all

Si

Why not using .xml files and TinyXML to parse them ?

I'll have a look at tinyXML, but I have no experience of xml....yet!! :)

I use an .cfg file for my configuration, which is like an .ini file on steroids, with some useful (for me) features. Basically, inside the file you can have variables (int, float, string or boolean), in namespaces, with comments and junk. My hand-rolled parser loads the file up as the first thing my engine does, and parses it into tokens, which are then evaluated and turned into usable variables. Because this only happens once, at load time, the preformance hit is negligable. A sample configuration file might look like this:

[+Ascendancy]	[+Startup]		ExecFile = "UserConfig.txt"		TerminateOnError = true		ViewDistance = 128.0		PlayerID = 12	[-Startup] 	ThrowFatalTestException = true	AutoCatchExceptions = true[-Ascendancy][+MyGame]	SomeGameVariable = 18523[-MyGame]

These are then easily readable by the client app through a simple ReadCFGValue(varname) function. Then, the icing on the cake is the ability to change the variables, and save the altered configuration file into an intermediate binary, which can be loaded on top of any other configuration file to apply those changes. So if I were to say, change, ThrowFatalTestException to false for some reason, I would opt to save the configuration, and that would create a binary file, Configuration.acfg, which could then, at any point in the future, be loaded over another configuration file, and would override it where there were 'conflicts'.

All in all, this works quite well for me, and, it was a really great learning experience making this work, but I really don't recommend rolling your own solution, unless you really do have the time to waste, because it was not terribly fun, spending about a month on debugging it. For about 1000 lines of code, it took an awful long time. So I guess my point is, don't reinvent the wheel unless you really want to, it's a thankless job!