visitingtool-concept.cpp File Reference

While laying the foundations for Session and Builder, Ichthyo came across the necessity to create a custom implementation of the Visitor Pattern optimally suited for Lumiera's needs. More...

Go to the source code of this file.

Description

While laying the foundations for Session and Builder, Ichthyo came across the necessity to create a custom implementation of the Visitor Pattern optimally suited for Lumiera's needs.

This implementation file was used for the drafting process and is self-contained. The final solution was then extracted later as library implementation into visitor.hpp

Basic considerations

• cyclic dependencies should be avoided or at least restricted to some library related place. The responsibilities for user code should be as small as possible.
• the purpose of Visitor is to achieve double dispatch, thus we can not avoid using some table lookup implementation, and we can not avoid using some of the cooperating classes' vtables. Besides that, the implementation should not be too wasteful...
• individual Visiting Tool implementation classes should be able to opt in or opt out on implementing functions treating some of the visitable subclasses.
• there should be a safe fallback mechanism backed by the visitable object's hierarchy relations. If some new class declares to be visitable, existing Visiting Tools not yet treating this new visitable type should fall back rather to the next best match up the hierarchy, instead of invoking some almost abstract base class.

See also

visitor.hpp the final lib implementation

visitingtooltest.cpp test cases using our lib implementation

BuilderTool one especially important instantiation

Definition in file visitingtool-concept.cpp.

#include "lib/test/run.hpp"
#include "lib/format-cout.hpp"
#include "lib/format-string.hpp"
#include "lib/depend.hpp"
#include <vector>

Namespaces
namespace	lumiera
	Lumiera public interface.
namespace	lumiera::visitor_concept_draft
namespace	lumiera::visitor_concept_draft::test

Macros
#define	DEFINE_PROCESSABLE_BY(TOOL)
	mark a Visitable subclass as actually treatable by some "visiting tool".

Typedefs
using	VisitingTool = Tool< void >

Classes
struct	TagTypeRegistry< TOOL, TOOLImpl >
class	Tag< TOOL >
class	Tool< RET >
	Marker interface "visiting tool". More...
class	ToolType< TOOLImpl, BASE >
	Mixin for attaching a type tag to the concrete tool implementation. More...
class	Dispatcher< TAR, TOOL >
	For each possible call entry point via some subclass of the visitable hierarchy, we maintain a dispatcher table to keep track of all concrete tool implementations able to receive and process calls on objects of this subclass. More...
class	Applicable< TAR, TOOLImpl, BASE >
	any concrete visiting tool implementation has to inherit from this class for each kind of calls it wants to get dispatched, Allowing us to record the type information. More...
class	Visitable< TOOL >
	Marker interface "visitable object". More...
class	HomoSapiens
class	Boss
class	BigBoss
class	Leader
class	Visionary
class	VerboseVisitor
class	Babbler
class	VisitingTool_concept

Functions
	LAUNCHER (VisitingTool_concept, "unit common")
	Register this test class...

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 treatable by some "visiting tool".

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

Definition at line 317 of file visitingtool-concept.cpp.