Page 1 of 1

Ogre ConfigFile

Posted: Mon Sep 16, 2019 11:33 am
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!

Re: Ogre ConfigFile

Posted: Wed Sep 18, 2019 10:43 pm
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).

Re: Ogre ConfigFile

Posted: Thu Sep 19, 2019 11:58 am
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!