visitor.hpp File Reference

A library implementation of the Visitor Pattern tailored specifically to Lumiera's needs within the Steam Layer. More...

Go to the source code of this file.

Description

A library implementation of the Visitor Pattern tailored specifically to Lumiera's needs within the Steam Layer.

Visitor enables double dispatch calls, based both on the concrete type of some target object and the concrete type of a tool object being applied to this target. The code carrying out this tool application (and thus triggering the double dispatch) need not know any of these concrete types and is thus completely decoupled form implementation details encapsulated within the visiting tool. The visiting tool implementation class provides specific "treat(ConcreteVisitable&)" functions, and this visitor lib will dispatch the call to the* correct "treat"-function based on the concrete target visitable type.

Implementation notes

• driven by dispatch tables with trampoline functions.
• uses Typelists and Template metaprogramming to generate Dispatcher tables for the concrete types.
• individual Visiting Tool implementation classes need to derive from some Applicable<TOOLImpl, Types<Type1,Type2,...> > instantiation and thus define which calls they get dispatched. This is crucial. A concrete type not declared in this way will never be dispatched to this concrete visiting tool implementation class. Of course, the latter is free to implement corresponding "treat(ConcreteVisitable&) functions or fall back on some treat(VisitableInterface&) function. - any concrete Visitable subclass wanting to be treated by some concrete tool needs to use the <tt>DECLARE_PROCESSABLE_BY(TOOLBASE)</tt> macro. By this, it gets an virtual <tt>apply(TOOLBASE\&)</tt> function. Otherwise, it will be treated by the interface of the next base class using this macro. @remarks as of 2016, it is not clear if we'll really use this facility; it was meant to play a crucial role in the Builder (which is not implemented yet....). The fundamental idea of relying on a visitor seems still adequate though. For design questions and more detailed implementation notes, see the <a href="http://lumiera.org/wiki/renderengine.html#VisitorUse%20VisitingToolImpl%20BuilderStructures%20BuilderMechanics" title="Lumiera Tiddly Wiki" >TiddlyWiki.

See also

visitingtooltest.cpp test cases using our lib implementation

BuilderTool one especially important instantiation

visitor-dispatcher.hpp

typelist.hpp

Definition in file visitor.hpp.

#include "lib/visitor-policies.hpp"
#include "lib/visitor-dispatcher.hpp"
#include "lib/meta/typelist.hpp"

Namespaces
namespace	lib
	Implementation namespace for support and library code.
namespace	lib::visitor

Macros
#define	DEFINE_PROCESSABLE_BY(TOOL)
	mark a Visitable subclass as actually treat-able by some "visiting tool" base interface.

Classes
class	Tool< RET, ERR >
	Marker interface / base class for all "visiting tools". More...
class	Applicable< TOOLImpl, typelist::Nil, BASE >
class	Applicable< TOOLImpl, typelist::Node< TAR, TYPES >, BASE >
class	Visitable< TOOL >
	Marker interface or base class for all "Visitables". More...

Macro Definition Documentation

DEFINE_PROCESSABLE_BY

#define DEFINE_PROCESSABLE_BY

(

TOOL

)

Value:

        virtual ReturnType  apply (TOOL& tool) \
        { return dispatchOp (*this, tool); }

mark a Visitable subclass as actually treat-able by some "visiting tool" base interface.

Defines the apply-function, which is the actual access point to invoke the visiting

Definition at line 222 of file visitor.hpp.