[boost] Re: Re: Making any visitable

From: Itay (itay_maman_at_[hidden])
Date: 2002-04-24 16:24:51

"Andrei Alexandrescu" <andrewalex_at_[hidden]> wrote in message
news:aa6lfb$4ia$1_at_main.gmane.org...
> "Itay Maman" <itay_maman_at_[hidden]> wrote in message
> news:aa6cii$g1u$1_at_main.gmane.org...
> > A couple of days ago, I made a post regarding a generic visitor
> called
> > Power_visitor, which is basically a static (i.e: compile time based)
> > visitor.
> [snip]
> >       typedef vany<t_visitor> t_any;
>
> The fact that you must parameterize the visited class with the visitor
> class is a disadvantage. Visitor's main purpose is to add new
> processing to types without changing the types themselves. If you must
> parameterize those types with the type of the visitor, then that
> requirement is not satisfied anymore.
>
>
> Andrei
>

That's true. Any's visitor does not meet the textbook's requirements for a
visitor class. Nonetheless it does have a 'visitorish' quality. Hence, I'll
try to outline the requirements for a boost::any semi-visitor:

(1) Retrieve the held value without using any_cast<>. This is the most
important requirement. If the code needs to apply any_cast<> to retrieve the
value of a boost::any object, it must store the target type somewhere, and
then use a switch statement to activate the correct any_cast<> call. This
procedure is awkward, clumsy, and error-prone.

(2) The visitor implementation should not rely on dynamic_cast<>'s. This is
due to efficiency considerations, which are relevant when implementing a
reusable component.

(3) The 'semi-visitor' should define a clean and concise scheme, for the
client code to 'plug-in' the functionality it wants to apply on the visited
objects.

(4) Type-safety.

Corollaries:

- Policies seem like the most natural technique to meet (3)
- The visitor should be static, (i.e: use compile time code generation).
This is imposed by (2) and (4)
- The implementation must somehow 'deliver' static type information to
any::holder, which is the only class that is aware of the type of the held
value. Since any::placeholder hides the any::holder data member under a
shield of virtual functions, there aren't many ways left to do that.
Parameterizing boost::any on the type of the visitor seems like a reasonable
compromise. (imposed by (1))

The Power_visitor class was designed to be a generic static visitor. Since
it is parameterized on two different polices it can safely visit almost any
type of host. In fact, its default visit policy allows a non-intrusive
visitation, so pre-made classes need no adjustments in order to become a
valid host.

However, When I modified Power_visitor to support visitation of boost::any
objects, I had to resort a less flexible policy, and, additionally,  I had
to parameterize any on the visitor type, which made it just a semi-visitor.
By all means, boost::any is not a usual class, so its visitor is a bit
eccentric, as well. Nonetheless, even when visiting anys, the concrete
functionality is defined by a (statically typed) policy. I believe that, for
most practical purposes, this is an acceptable degree of freedom.

-Itay.

>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>