visitingtool-concept.cpp File Reference

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.
• Visitor is about double dispatch, thus we can't avoid using some table lookup implementation, and we can't 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>

Classes
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	Babbler
class	BigBoss
class	Boss
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	HomoSapiens
class	Leader
class	Tag< TOOL >
class	Tag< TOOL >
struct	TagTypeRegistry< TOOL, TOOLImpl >
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	VerboseVisitor
class	Visionary
class	Visitable< TOOL >
	Marker interface "visitable object". More...
class	VisitingTool_concept

Typedefs
typedef Tool< void >	VisitingTool

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

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

Namespaces
	lumiera
	Lumiera public interface.

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 327 of file visitingtool-concept.cpp.

Function Documentation

LAUNCHER()

lumiera::visitor_concept_draft::test::LAUNCHER	(	VisitingTool_concept	,
		"unit common"
	)

Register this test class...