Re: Const Considerations (revisited)
audiofanatic@gmail.com (Craig Scott) wrote (abridged):
One of the more common ones is when you want to respond to an event by
sending something to std::cout. The observer doesn't change itself or
any data it holds internally if that is all it needs to do. One could
make arguments for and against whether sending something to std::cout
should be considered a const or non-const operation in this context.
The point, however, is that the compiler considers it const for the
observer (for example, any const member function can send text to
std::cout).
The compiler often gets these things wrong. It's the same if the stream is
held as a pointer instance variable:
struct Observer {
ostream *pStream;
void onEvent() const {
*pStream << "hello, world\n";
}
};
The const-ness of Observer does not imply the const-ness of what Observer
points to. This is because pointers implement different kinds of relation
and the compile can't guess what we mean.
Personally I'd tend to see this as non-const, and in the cout example too
where the changed object is a global. (I rarely use std::cout; I try to
avoid globals.) To the point where it would be reasonable to create a
non-const object to deal with the stream, and a const object to deal with
the immutable state.
The whole point of the observer pattern is so that the event initiator
doesn't have to know anything at all about observing clients other
than that they are interested in a particular event.
(I was talking about a variant of the pattern where the observer returns
results, as part of trying to figure out why you might want observers
which didn't change state.)
Clearly, if you don't want the event source to know anything about the
observers, then it can't know whether they are const, so you have to use
some kind of abstraction barrier. It seems best to define a non-const
observer interface and then use some kind of wrapper to deal with const
observers, to make them look like non-const ones, rather than vice versa.
Is it that hard? You can just have the non-const notification function
call the const one.
Yep, but that means that the observer itself can never be created as a
const object, even if it has no data members and no other non-const
member functions. This seems like an unnecessary limitation.
Then put the functions in different objects.
So the 3 approaches are:
(1) Give the observer a non-const function which calls a const one on
itself.
(2) Use a non-const wrapper object around immutable objects.
(3) Let the event source know whether observers are const and keep them in
two lists, one for each type.
The final approach is probably the most efficient if const observers are
common. For me they are very rare, for reasons I've explained.
-- Dave Harris, Nottingham, UK.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]