|
Boost : |
Subject: Re: [boost] interest in generic cyclic visitor?
From: Jan Herrmann (jherrmann79_at_[hidden])
Date: 2012-08-06 12:03:11
On 03.08.2012 13:58, Sohail Somani wrote:
> On 03/08/2012 3:17 AM, Jan Herrmann wrote:
>> Additionally it can be used as a base for multimethod implementation.
>
> This is much more interesting to me. Can you elaborate or give some
> sample code?
>
Here is an example. In contrast to other examples I prefer hiding
visitor objects in normal functions to place them in different
translation units and make them easier to use. The main aspect of my
multimethod (and visitor) implementation is the forwarding to a non
polymorphic function object preserving the constness of its arguments.
It can be templated and you can use all aspects of static polymorphism
for implementing operator(). At compile time it generates a polynomial
amount of code to forward to the user specified function object (for
this example 3 polymorphic classes, 3 intermediate static visitors and
in sum 6 virtual functions). The dispatch actually needs 2 virtual calls
per polymorphic parameter (in this example 4 calls). It will detect all
ambiguities at compile time and if you add new classes to a hierarchy
you have to recompile everything. Depending on your static visitors
(function objects) it will use base classes, a generic solution or
compilation will fail.
Please be aware that my intention for my library was an generic
implementation of an GoF visitor. The multimethod implementation was not
my primary concern but at this time it is implemented within 65 lines of
(yet undocumented) code. My multimethod implementation needs only a
special templated accept function which can be implemented for cyclic
visitable classes, boost::variant, an wrapper for boost::any and other
types with polymorphic behavior. If there is interest in my library I
will implement a more generic way of using these visitors. Additional to
the dispatching mechanism it will handle parameter and return value
transportation.
Jan Herrmann
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk