[boost] Re: Re: Proposal: Visitor

From: Itay (itay_maman_at_[hidden])
Date: 2002-07-09 06:04:53

Hi Mac,

Templates and virtual functions do not mix. A virtual base class creates a
'firewall' which, has the nice effect of allowing polymorphic objects to
pass thru, but, on the other hands, it hides any concrete type information.
This, obviously, reduces the knowledge the compiler has about the passed-in
visitor, and decreases flexibility.

As for the inc_by_10_visitor, I do agree with you that a template member
function offers even more power, I just wanted to give a quick example to
clarify the point. [I was using the well known "clarify-by-code" idiom
:)....].

Anyway, I did look at the example and I saw that you did not try to visit
boost::any  objects. We still need a virtual base class which can be passed
thru boost::any::placeholder. And I just don't see how your code offers
that. (Again, Il'l be happy to stand corrected). In other words: If you only
need to visit simple classes (non any-like data types) there's no need for
all this inheritance.

You can also look here:
http://lists.boost.org/MailArchives/boost/msg31604.php

-Itay

"Mac Murrett" <mmurrett_at_[hidden]> wrote in message
news:0C9289A4-8EAE-11D6-BD36-003065F959FC_at_vanteon.com...
> Itay, thanks for responding!
>
>
> >> I have been looking at the implementations of variant classes
> >> floating by here, and while I have been happy with aspects of them,
> >> I am not happy with the visitability of any of them.
> > Could you elaborate on that?
>
> It seems that we disagree about what is desirable in a visitor
> base, but I will try.  The principal disadvantage of the other
> implementations that I have seen is that they lack a
> virtually-dispatched base class.  This means that they cannot be
> passed down an inheritance hierarchy, so we have to have a hack for
> our visitation implementation.  With a base class for our visitor,
> we can have a virtual accept method on an any-like placeholder and
> holder<T>.
>
>
> > The main disadvantage of this implementation -  when compared to
> > the visitor
> > in the suggested variants implementations -
> > is that it is too strict. You must supply an appropriate
> > visit_impl member
> > function for each type on the type-list. This increases
> > code duplication, since its very likely that you can handle
> > several types by
> > one function. To clarify this point, here is a concrete visitor
> > which, I think,  cannot work with your suggested boost::visitor:
> >
> > struct inc_by_10_visitor : visitor<int, short, unsigned int, char>
> > {
> >     void visit_impl(int x)
> >     {
> >         cout << "result = " << x+10 << endl;
> >     }
> >
> > };
>
> As stated above, I think that the use of virtuals is a key benefit,
> but I agree that being able to trivially implement something like
> your example would be nice.  Happily, there is a trivial TMP-based
> solution to this.  This is still not perfect, though, so we'll go
> the extra mile.  Your example relies on the ability to cast
> everything to a "mother type", in this case, int.  What would be
> far superior would be:
>
> struct inc_by_10_visitor2
> {
> template<typename T>
>      void visit_func(T &x)
>      {
>          cout << "result = " << x + 10 << endl;
>      }
> };
>
> We can support both of these by having an adapter template that
> creates a visitor from a type list and anything that provides
> visit_func suitable for all types in the list.
>
> I have uploaded it to the files section at
> http://groups.yahoo.com/group/boost/files/visitor.zip, but the gist
> is that it derives from both visitor<list> and a user-specified
> class, and implements the visit_impl functions to call a function
> in the user-specified class.  See the example named
> inc_by_10_visitor for an example.
>
> Thanks again for the feedback,
> Mac Murrett.
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>