Re: Const Considerations (revisited)
audiofanatic@gmail.com (Craig Scott) wrote (abridged):
That whole discussion bothered me because I knew there was a
particular scenario for which maintaining const correctness was near
impossible. I've since been able to nail it down to applications which
make use of the observer design pattern. Trying to use observers
without any form of const_cast makes it very difficult to use const
for any functions which may be called as a result of an observed
event. This is because when an event is triggered, the event initiator
doesn't know if observers of that event can be called as const or not.
Do you have a motivating example? On the face of it, it's not obvious to
me how an observer can usefully respond to an event without changing.
I suppose it could forward the event to another object which changes,
while not changing itself, but in this situation I'd be happy to consider
the observer to be as non-const as the thing it is delegating to.
An exception is when the observer merely calculates a result which it
returns back to the event initiator. (I don't think this is a classic
Observer pattern any more, but never mind.) In this case surely the
observer /is/ logically const, and the notification function should be
declared as such. I think it's then appropriate to use some subterfuge to
get around const if you want something different, rather like if you want
your functors to have state with certain std algorithms.
In general I think I'd expect to know at design time what kind of observer
a given event expected to have. The same event source might produce
several different events and so want to support both const and non-const
observers, but it can do that by keeping (at least) two lists of observers
and using the event type to determine which to use.
I am wondering whether you have some kind of observer framework which
enforces homogeneous events? If so then this is a classic "man in the
middle" which is often a problem for static type checking. (That is, how
to pass an object from A to B to C, where A knows the object's exact type
and C needs it, but B is some generic library or O/S or collection that
doesn't know it. The usual solutions being either to make B a template,
effectively duplicating a B for each type, or else use some form of
type-test such as dynamic_cast or Visitor or multi-methods.)
1. Notify observers of the event with a non-const function.
2. Raise two events, one as non-const and one as const. The observers
then need to specifiy whether they want to observe the event as const
or non-const when attaching to the subject.
Most implementations of the observer pattern that I've seen in
practice choose option 1, which makes it very hard for all client code
related to observers hard to keep const-correct.
Is it that hard? You can just have the non-const notification function
call the const one.
class Observer {
public:
void OnEvent() = 0;
};
class ConstObserver : public Observer {
private:
virtual void OnEvent() { OnConstEvent(); }
virtual void OnConstEvent() const = 0;
};
You can build an error-checking framework if it helps:
class BaseObserver {
public:
void OnBaseEvent() { OnBaseEvent( PrivateTag() ); }
private:
friend class Observer;
friend class ConstObserver;
struct PrivateTag {};
virtual void OnBaseEvent( PrivateTag t ) = 0;
};
class Observer : public BaseObserver {
private:
virtual void OnBaseEvent( PrivateTag t ) { OnEvent(); }
protected:
virtual void OnEvent() = 0;
};
class ConstObserver : public BaseObserver {
private:
virtual void OnBaseEvent( PrivateTag t ) { OnConstEvent(); }
protected:
virtual void OnConstEvent() const = 0;
};
Client code inherits either from ConstObserver or Observer and overrides
the const or non-const event function respectively. I have used PrivateTag
to prevent other classes overriding OnBaseEvent inappropriately, just to
show it can be done, but frankly I doubt that would happen by accident
anyway. (Java's "final" keyword would be useful here.)
This version has an extra virtual function call, but I think you can
eliminate it by using templates and the Recursively Recurring idiom.
-- Dave Harris, Nottingham, UK.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]