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