visitor design pattern, loki and more

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • aaragon

    #1

    visitor design pattern, loki and more

    Hello everyone,

    I've been trying to work with the visitor design pattern, and it works
    fine except for the following.
    Let's suppose that we have a fixed hierarchy of classes (many of them)
    which I cannot modify. I decided to use the visitor design pattern
    depending on the actual type of the classes because those classes
    already support the loki visitor.

    #include <Loki/Visitor.h>

    // forward declarations
    class Class_base;
    class Class1;
    class Class2;
    ....
    class Class20;

    // Class list, all derive from Class_base and they all accept the
    visitor design pattern through
    // the loki visitor
    typedef LOKI_TYPELIST_2 0(Class1, Class2,...,Clas s20) ClassList;
    //! Class visitor
    typedef Loki::CyclicVis itor<void, ClassList ClassVisitor;


    class VisitorImpl : public ClassVisitor {

    // treat visitor as a functor
    void operator(Class_ base& b) { b.Accept(*this) ; }

    ReturnType Visit(Class1& c1) { // do stuff with Class1; }
    ReturnType Visit(Class2& c2) { // do stuff with Class2; }
    ...
    ReturnType Visit(Class20& c20) { // do stuff with Class20; }
    };


    Well, this works well, but it seems very silly to add 20 different
    lines if each of those functions call to a templated function in their
    implementation called Compute (that's why this function is not
    virtual). So I decided to give a try to the hierarchy generator (also
    provided by loki) as follows:

    template <class Class>
    class ClassComputerUn it {

    public:
    virtual typename ClassVisitor::R eturnType Visit(Class& el) {
    // call Compute function
    }
    virtual ~ClassComputerU nit() {}
    };

    class VisitorImpl : public ClassVisitor, public
    GenScatterHiera rchy<ClassList, ClassComputerUn it {

    // ... unrelated stuff

    // create visitor as a functor
    void operator(Class_ base& b) { b.Accept(*this) ; }

    // all 20 Visit functions don't show up anymore, they are supposed
    to be inherited through the
    // GenScatterHiera rchy generator
    };


    Now, what GenScatterHiera rchy does, is to derive from
    ClassComputerUn it<Classwhere Class is each of those classes in the
    ClassList. So now I'm supposed to have all 20 Visit functions in the
    VisitorImpl class overide the one of the Visitor. However, this is not
    the case and I cannot compile my code because there are pure virtual
    functions. So in a sense the GenScatterHiera rchy did not overide the
    Visit function from the visitor as I thought it would.

    Does anyone have a clue why is this happening? I'm using GCC4.3.
    Thanks in advance for the time reading such a long post.

    aa
  • mlimber

    #2
    Re: visitor design pattern, loki and more

    On Aug 12, 3:25 pm, aaragon <alejandro.ara. ..@gmail.comwro te:
    Hello everyone,
    >
    I've been trying to work with the visitor design pattern, and it works
    fine except for the following.
    Let's suppose that we have a fixed hierarchy of classes (many of them)
    which I cannot modify. I decided to use the visitor design pattern
    depending on the actual type of the classes because those classes
    already support the loki visitor.
    [...]
    Now, what GenScatterHiera rchy does, is to derive from
    ClassComputerUn it<Classwhere Class is each of those classes in the
    ClassList. So now I'm supposed to have all 20 Visit functions in the
    VisitorImpl class overide the one of the Visitor. However, this is not
    the case and I cannot compile my code because there are pure virtual
    functions. So in a sense the GenScatterHiera rchy did not overide the
    Visit function from the visitor as I thought it would.
    >
    Does anyone have a clue why is this happening? I'm using GCC4.3.
    Thanks in advance for the time reading such a long post.
    This is rather beyond the scope of this group, IMHO (cf.
    http://www.parashift.com/c++-faq-lit....html#faq-5.9). Have
    you asked on the Loki help forum on Sourceforge? Or can you boil it
    down to a standard C++ question?

    Cheers! --M

    Comment

    • aaragon

      #3
      Re: visitor design pattern, loki and more

      On Aug 12, 2:34 pm, mlimber <mlim...@gmail. comwrote:
      On Aug 12, 3:25 pm, aaragon <alejandro.ara. ..@gmail.comwro te:
      >
      >
      >
      Hello everyone,
      >
      I've been trying to work with the visitor design pattern, and it works
      fine except for the following.
      Let's suppose that we have a fixed hierarchy of classes (many of them)
      which I cannot modify. I decided to use the visitor design pattern
      depending on the actual type of the classes because those classes
      already support the loki visitor.
      [...]
      Now, what GenScatterHiera rchy does, is to derive from
      ClassComputerUn it<Classwhere Class is each of those classes in the
      ClassList. So now I'm supposed to have all 20 Visit functions in the
      VisitorImpl class overide the one of the Visitor. However, this is not
      the case and I cannot compile my code because there are pure virtual
      functions. So in a sense the GenScatterHiera rchy did not overide the
      Visit function from the visitor as I thought it would.
      >
      Does anyone have a clue why is this happening? I'm using GCC4.3.
      Thanks in advance for the time reading such a long post.
      >
      This is rather beyond the scope of this group, IMHO (cf.http://www.parashift.com/c++-faq-lit....html#faq-5.9). Have
      you asked on the Loki help forum on Sourceforge? Or can you boil it
      down to a standard C++ question?
      >
      Cheers! --M
      It is a standard C++ question. It does not matter which kind of
      visitor you use, all of them boil down to having a pure virtual
      function in a base class, and have all subclasses override that
      function. The GenScatterHiear chy class template is basically a
      metaprogram, so it is a shorthand version of public Class1, public
      Class2, and so on.

      aa

      Comment

      • mlimber

        #4
        Re: visitor design pattern, loki and more

        On Aug 12, 4:32 pm, aaragon <alejandro.ara. ..@gmail.comwro te:
        On Aug 12, 2:34 pm, mlimber <mlim...@gmail. comwrote:
        >
        >
        >
        On Aug 12, 3:25 pm, aaragon <alejandro.ara. ..@gmail.comwro te:
        >
        Hello everyone,
        >
        I've been trying to work with the visitor design pattern, and it works
        fine except for the following.
        Let's suppose that we have a fixed hierarchy of classes (many of them)
        which I cannot modify. I decided to use the visitor design pattern
        depending on the actual type of the classes because those classes
        already support the loki visitor.
        [...]
        Now, what GenScatterHiera rchy does, is to derive from
        ClassComputerUn it<Classwhere Class is each of those classes in the
        ClassList. So now I'm supposed to have all 20 Visit functions in the
        VisitorImpl class overide the one of the Visitor. However, this is not
        the case and I cannot compile my code because there are pure virtual
        functions. So in a sense the GenScatterHiera rchy did not overide the
        Visit function from the visitor as I thought it would.
        >
        Does anyone have a clue why is this happening? I'm using GCC4.3.
        Thanks in advance for the time reading such a long post.
        >
        This is rather beyond the scope of this group, IMHO (cf.http://www.parashift.com/c++-faq-lit....html#faq-5.9). Have
        you asked on the Loki help forum on Sourceforge? Or can you boil it
        down to a standard C++ question?
        >
        Cheers! --M
        >
        It is a standard C++ question. It does not matter which kind of
        visitor you use, all of them boil down to having a pure virtual
        function in a base class, and have all subclasses override that
        function. The GenScatterHiear chy class template is basically a
        metaprogram, so it is a shorthand version of public Class1, public
        Class2, and so on.
        MFC, Qt, and many other libraries would also qualify under such a
        definition of standard C++. Can you rephrase the question so that we
        can answer it by looking at the C++ standard? One way to do that is to
        boil it down to a minimal but complete program that demonstrates your
        problem. (Note, you'll likely get more help if it doesn't require
        downloading Loki.)

        Cheers! --M

        Comment

        Working...