Ogre ConfigFile

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

Ogre ConfigFile

Post by luis » Mon Sep 16, 2019 11:33 am

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!
0 x

paroj
OGRE Team Member
OGRE Team Member
Posts: 924
Joined: Sun Mar 30, 2014 2:51 pm
x 209
Contact:

Re: Ogre ConfigFile

Post by paroj » 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).
0 x

User avatar
luis
Greenskin
Posts: 119
Joined: Tue Mar 02, 2004 3:33 pm
Location: Spain / Argentina
x 4
Contact:

Re: Ogre ConfigFile

Post by luis » Thu Sep 19, 2019 11:58 am

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!
0 x

Post Reply