Re: Class hierarchy on visitor side of visitor pattern
On Jul 27, 4:36 am, Rune Allnor <all...@tele.ntnu.no> wrote:
Hi!
I think that your problem has little to do with patterns and more with
how C++ and similar languages work. In here:
class BaseVisitor{
public:
virtual BaseVisitor& visit(Base*) = 0;
virtual BaseVisitor& display(derived1*) = 0;
virtual BaseVisitor& display(derived2*) = 0;
};
class DerivedVisitor : public BaseVisitor {
public:
DerivedVisitor& visit(Base* b)
You first say that you want BaseVisitor::visit to return BaseVisitor&,
then that you want DerivedVisitor&. I fail to see the purpose of that.
This is a no-no in C++, and probably in some other languages. Ask
yourself: what is the point of a virtual function that returns two
different types of result? "virtual" implies polymorphism, but what
you ask is called overloading, at least in C++. Not the same. On top
of that, it doesn't work well in C++ for return types.
And of course, your implementation (return (b->dispatchType(this)))
rightly makes compiler barf: result type of dispatchType is
BaseVisitor&, but result type of DerivedVisitor::visit is
DerivedVisitor&. Since BaseVisitor is NOT a DerivedVisitor, compiler
doesn't let you do that (note that DerivedVisitor IS-A BaseVisitor,
though).
Your second issue is a consequence of the first, here:
int main()
{
DerivedVisitor v;
derived1 d1;
derived2 d2;
size_t s = v.visit(&d1).getState(); // <<<< I want this syntax,
not...
Why? Well, in it's specified form (in BaseVisitor), "visit" should not
give you something you can call "getState" on: this is just not
specified in the "spec" you made yourself (as specified by
BaseVisitor::visit). Note that you can clearly have a derived visitor
that has getState, but if you try one without, then what about your
code?
If you still want this particular syntax (but I would argue it's a
poor design), you can do:
size_t s = static_cast<DerivedVisitor&>(v.visit(&d1)).getState();
That is, for a specific derivation, you make a specific use-case (as
shown here through static_cast).
If, OTOH, your getState is in fact common use-case, then it should be
in BaseVisitor, along virtual visit etc.
HTH,
Goran.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]