Re: Correct constness
worndown@gmail.com (Vadim) wrote (abridged):
Now, ConfigManager::GetSettings should return pointer to non-const
Settings, so caller can modify the settings.
That's debatable - it depends on whether the Settings are "part of" the
ConfigManager. Usually member variables like s_ do represent a "part of"
relationship, especially if they are "owning" (eg the ConfigManager is
responsible for deleting the settings). You don't show enough code for me
to be sure. The word "Manager", when used as a class name, can be a bit
vague.
If X is const, then anything which is part of X should also be const. So
for const-correctness you need to think carefully about what relationships
your pointers are implementing.
The question is whether SetSettings itself should be const member
or not?
It should not be const. The choice of which Settings the ConfigManager
uses is surely part of the visible state of the ConfigManager, and a
member function which changes the visible state should not be const.
Given the code above, it doesn't really matter, because it doesn't make
much difference (at least to me).
Is that because you will never actually have a reference to a const
ConfigManager object?
You should find the code:
void ConfigManager::SetSettings( Settings *s ) const {
s_ = s;
}
will not compile, which is surely a clue.
-- Dave Harris, Nottingham, UK.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]