Emulator Issues #2711

IniFile code replacement

Added by Billiard26 over 10 years ago.

% Done:


Operating system:
Issue type:
Relates to usability:
Relates to performance:
Relates to maintainability:
Regression start:
Fixed in:


I have replaced Dolphin's IniFile code with the IniFile code used by the
New GCPad and Wiimote plugins.

The proposed IniFile is a class which inherits:
map< string, map< string, string > >
along with additional Get/Set/Load/Save... methods like the current inifile

// Because IniFile and Sections inherit std::map, values can be accessed
like so:

inifile["section_name"]["key_name"] = "value";
some_string = inifile["section_name"]["key_name"];

// Get/Set can still be used:
// Get/Set methods are of the Section class now, rather than the IniFile class

inifile["section_name"].Get("key_name", &some_int, 5);
// very similar to the current syntax
//inifile.Get("section_name", "key_name", &some_int, 5);

// current code:

//iniFile.Set("Real", "AccNeutralX", iAccNeutralX);
//iniFile.Set("Real", "AccNeutralY", iAccNeutralY);
//iniFile.Set("Real", "AccNeutralZ", iAccNeutralZ);

// this can be(it is in the patch) replaced with:

Section& real = iniFile["Real"];
real.Set("AccNeutralX", iAccNeutralX);
real.Set("AccNeutralY", iAccNeutralY);
real.Set("AccNeutralZ", iAccNeutralZ);

// ...a reference to the section "Real" can be created
// so searching the inifile for the same section (sometimes 15+ times) is
not needed


- Less code to maintain
Current: IniFile.cpp 526 lines, IniFile.h 92 lines
Proposed: IniFile.cpp 255 lines, IniFile.h 123 lines
templates are used for Get()/Set() methods
extra code to find sections/keys is not needed, because of inheriting
std::map methods

- Comments are completely ignored and Removed from an inifile after saving

  • GetLines()/SetLines() functionality is somewhat hacked in.
    After {Get,Set}Lines is called on a Section, the normal Get/Set
    functions will have no effect on the saved file.
    These functions are used to access non-inifile syntax lines for AR codes
    in the game ini files.
    These lines don't belong in inifiles anyway.

  • Bigger file sizes
    Dolphin.exe +30KB
    Plugin_DSP_HLE +60KB
    Plugin_GCPad.dll +80KB
    Plugin_Wiimote.dll +90KB

Being a std::map, saved files automatically have alphabetized sections
and keys.
Mostly good, but someone might not like this.

I want to know if anyone opposes the changes, or if I should commit them.


#1 Updated by death2droid over 10 years ago

Personally I don't really like the way your ini file code works at all.

#2 Updated by Billiard26 over 10 years ago

Can you explain?

#3 Updated by omegadox over 10 years ago

its pro :P

#4 Updated by hrydgard over 10 years ago

Inheriting std::map seems mildly crazy and not something I'd ever do. Is that really a
good idea? Isn't it better just to mimic the interface and use an std::map in the

#5 Updated by Billiard26 over 10 years ago

I thought it made a lot of sense to just inherit it. This way the iterators can be
used, along with all the other map features (find,size,begin...) without needed to
create methods for them. Doing something like this for each needed function seems
silly to me:
size_t IniFile::size() const {return m_internal_map.size();}

#6 Updated by BhaaL over 10 years ago

I already said that on IRC, but the presence of [GS]etLines is clearly an indication
of things being used in the wrong way.

Putting aside the fact that it derives from std::map, I'd say it is a good change - but.
But, [GS]etLines should be removed, and code using it should be rewritten to use
something else; and even if it is just the old IniFile code, tailored to its
requirements (i think AR Codes and Debugger BPs use it) - and renamed ofc to make the
changes complete.

#7 Updated by Anonymous over 10 years ago

Great, seems like I committed it either without reading this issue or totally
forgetting about it.
Well, sorry...hopefully it will not be too time consuming to fix if the change is just
inside the IniFile class itself.

#8 Updated by Anonymous over 10 years ago
I think in IniFile's case, it is ok because: we never expect to use Section or
IniFile classes as std::map<> polymorphically, and the inherited classes "are" a
std::map, not "containing" a std::map<>, so it also makes sense from a design point
of view.

#10 Updated by Anonymous about 9 years ago

  • Status changed from New to Fixed

Ignore this...Status:Verified was removed, changing to Fixed

Also available in: Atom PDF