Ogre ConfigFile

What it says on the tin: a place to discuss proposed new features.
User avatar
luis
Greenskin
Posts: 122
Joined: Tue Mar 02, 2004 3:33 pm
Location: Spain / Argentina
x 7

Ogre ConfigFile

Post by luis »

Hi,
I've been using Ogre ConfigFile for years in my projects extending the class functionality by composition. Now the latest Ogre version 1.x (and I suppose the v2.x) is deprecating this method:

Code: Select all

 /// @deprecated use getSettingsBySection()
 OGRE_DEPRECATED SectionIterator getSectionIterator(void);
in favor of:

Code: Select all

/** Get all the available settings grouped by sections */
const SettingsBySection_& getSettingsBySection() const {
 return mSettings;
}
The problem is the const in the return value because I can't modify the values in a given section/key and then save it to disk and since the class isn't prepared to be a base class I won't be able to extend it by inheritance neither.

I'd like to extend it by composition (I don't like the general promiscuity of the inheritance). Please consider making it non-const in the get member or at least add a virtual destructor :)
thank you!
paroj
OGRE Team Member
OGRE Team Member
Posts: 2108
Joined: Sun Mar 30, 2014 2:51 pm
x 1134

Re: Ogre ConfigFile

Post by paroj »

as the class does not offer any write functionality, a mutable interface does not seem necessary. On the other hand a const interface doing allows in-site parsing in the future.
Your use-case is of course valid, however I do think the default interface should satisfy the general case while making API stability guarantees easy.

As a composition workaround I would recommend just copying SettingsMultiMap to the outer class.
Alternatively inheritance is actually safe as the class does not have any virtual functions (being essentially POD).
User avatar
luis
Greenskin
Posts: 122
Joined: Tue Mar 02, 2004 3:33 pm
Location: Spain / Argentina
x 7

Re: Ogre ConfigFile

Post by luis »

paroj wrote: Wed Sep 18, 2019 10:43 pm as the class does not offer any write functionality, a mutable interface does not seem necessary. On the other hand a const interface doing allows in-site parsing in the future.
Your use-case is of course valid, however I do think the default interface should satisfy the general case while making API stability guarantees easy.

As a composition workaround I would recommend just copying SettingsMultiMap to the outer class.
Alternatively inheritance is actually safe as the class does not have any virtual functions (being essentially POD).
I like the workaround you propose, I'll go that route ;)
I didn't realize it was a POD, you are right.
Thank you for your help!