   using ini files
  Hello,I want to use an .ini file to load and save various game related variables.Can anyone please explain how you extract variables, and also write to an ini file?thanksSimon   
  You must do everything yourself.  You can either use Window's Get/WritePrivateProfileString, or recreate everything.  Here is one way using Get/WritePrivateProfileString.#include "PrecompiledHeaders.h"#pragma hdrstop#include "WinIniFile.h"#include "RMW_Utilities.h"#include <stdio.h>   //for sprintf#include <string>TCHAR WinIniFile::bufferC[] = { 0 };WinIniFile::WinIniFile(wString const & fileName) : fileNameC(fileName) { }int WinIniFile::read(TCHAR * secName, const TCHAR * keyName, int defVal) {   int numCopied = GetPrivateProfileString(secName, keyName, rmw::itoa(defVal).c_str(),WinIniFile::bufferC, BufLen, fileNameC.c_str());   if (!numCopied) return defVal;   if (!rmw::validIntStr(WinIniFile::bufferC, BufLen)) return defVal;   #ifdef UNICODE return _wtoi(WinIniFile::bufferC);   #else return atoi(WinIniFile::bufferC); #endif   }void WinIniFile::write(TCHAR * secName, const TCHAR * keyName, int val) {   #ifdef UNICODE _itow(val, WinIniFile::bufferC, 10);   #else itoa(val, WinIniFile::bufferC, 10); #endif   WritePrivateProfileString(secName, keyName, WinIniFile::bufferC, fileNameC.c_str());   }wString WinIniFile::read(TCHAR * secName, const TCHAR * keyName,  wString const & defStr) {   int numCopied = GetPrivateProfileString(secName, keyName, defStr.c_str(),WinIniFile::bufferC, 2047, fileNameC.c_str());   if (!numCopied) return defStr;   return WinIniFile::bufferC;   }void WinIniFile::write(TCHAR * secName, const TCHAR * keyName, wString const & str) {   WritePrivateProfileString(secName, keyName, str.c_str(), fileNameC.c_str());   }void WinIniFile::writeBool(TCHAR * secName, const TCHAR * keyName, bool val) {   wString str (val ? TEXT("true") : TEXT("false"));   WritePrivateProfileString(secName, keyName, str.c_str(), fileNameC.c_str());   }bool WinIniFile::readBool(TCHAR * secName, const TCHAR * keyName, bool defVal) {   int numCopied = GetPrivateProfileString(secName, keyName, defVal ? TEXT("true") :TEXT("false"), bufferC, BufLen, fileNameC.c_str());   if (!numCopied) return defVal;   wString str = bufferC;   if (str == TEXT("TRUE") || str == TEXT("true")) return true;   return false;   }double WinIniFile::readFloat(TCHAR * secName, const TCHAR * keyName, float defVal) {   int numCopied = GetPrivateProfileString(secName, keyName, rmw::textStr(defVal).c_str(),bufferC, BufLen, fileNameC.c_str());   if (!numCopied) return defVal;   wString str = bufferC;   #ifdef UNICODE return wcstod(bufferC, NULL);   #else return atof(bufferC); #endif   }void WinIniFile::writeFloat(TCHAR * secName, const TCHAR * keyName, float val) {   #ifdef UNICODE swprintf(bufferC, TEXT("%.3f"), val);   #else sprintf(bufferC, TEXT("%.3f"), val); #endif   WritePrivateProfileString(secName, keyName, bufferC, fileNameC.c_str());   }Holler if you want the blanks filled in.   ;  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.   ;Quote:Original post by IllcoYou should actually store this information in the registry......if you want your system boot times to increase, as well as various other activities that are affected by having a bloated registry.  That is why MS is now advocating not using the registry, or so I hear.  I think they are advocating XML files now.At least using ini files only slows down your program (as do XML files).  And as Extarius said, you can wrap ini files yourself to further decrease the hit, as well as designing your program up-front so that the hit only occurs at program startup and shutdown.   ;  thanks, anon, for the extensive code.I may well parse the file into a map as Ex suggests.Thanks allSi   ;  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 = trueViewDistance = 128.0PlayerID = 12[-Startup] ThrowFatalTestException = trueAutoCatchExceptions = true[-Ascendancy][+MyGame]SomeGameVariable = 18523[-MyGame]These are then easily readable by the client app through a simple ReadCFGValue<type>(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!   