Emulator Issues #2711
closedIniFile code replacement
0%
Description
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
code.
// 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
Patch: http://billiard.us.to/share/Dolphin/inifile_replacement.patch
Pros:
-
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 -
Performance
http://pastie.org/954684
Get()/Set() methods are 90x faster!
Cons:
-
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
etc...
Pro/Con:
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.
Thanks
Updated by death2droid over 14 years ago
Personally I don't really like the way your ini file code works at all.
Updated by hrydgard over 14 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
implementation?
Updated by Billiard26 over 14 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();}
Updated by BhaaL over 14 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.
Updated by Anonymous over 14 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.
Updated by Anonymous over 14 years ago
http://en.allexperts.com/q/C-1040/possible-inherit-classes-STL.htm
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.
Updated by Anonymous over 13 years ago
- Status changed from New to Fixed
Ignore this...Status:Verified was removed, changing to Fixed