|
The Boost Statechart Library
Configuration
|
- General configuration
- Introduction
- Debug mode compilation
options
- Release mode compilation
options
- Application Defined
Macros
The library uses several configuration macros in <boost/config.hpp>, as well as
two configuration macros meant to be supplied by the application. Moreover,
two commonly available compiler options also have an impact on the
available features.
- C++ RTTI must be turned on (used by various asserts)
- C++ exception handling can be turned on or off. When turned off,
obviously the library's error
handling support is no longer available
- C++ RTTI can be turned on or off. When turned off, the use of
state_cast<>()
leads to a compile time error (state_downcast<>() is
still available). Moreover, BOOST_STATECHART_USE_NATIVE_RTTI
must not be defined simultaneously
- C++ exception handling can be turned on or off. When turned off,
obviously the library's error
handling support is no longer available
The following macros may be defined by an application using the
library:
Macro |
Meaning |
BOOST_STATECHART_USE_NATIVE_RTTI |
When defined, the library no longer uses its own speed-optimized RTTI
implementation. Instead, native C++ RTTI is employed (see RTTI customization in the
performance document for more information). This has the following
effects:
state_machine::state_base_type becomes a
polymorphic type. That is, when typeid is applied to a
state_machine::state_base_type reference, the result
refers to a type_info object representing the the type
of the most derived state type
- Custom state
type information is no longer available
- All states need to store one pointer less, leading to a
best-case state machine memory footprint reduction of about
15%
- Under most circumstances, dispatch speed degrades. This is
because native C++ RTTI values are retrieved through an additional
indirection on almost all platforms. See Speed versus
scalability tradeoffs in the performance document for
timings
|
BOOST_STATECHART_RELAX_TRANSITION_CONTEXT |
When defined, the sequence of actions that are called
during a transition is relaxed. That is, its is no longer necessary
that all states up to the innermost common context are exited before
the transition action is called (as mandated by the UML standard).
Instead, the transition action can be a member of either the transition
source or any direct or indirect outer context and is called as soon as
all possibly active inner states have been exited. Then all remaining
active states up to the innermost common context are exited before
entering all states down to the transition destination |
Both macros need to be consistently defined or undefined for all
translation units that are later linked into the same executable. Not doing
so will inevitably lead to ODR violations. Depending on compiler and linker
technology such violations may or may not manifest themselves in link-time
errors.
Revised 05 January, 2008
Copyright © 2003-2008 Andreas Huber
Dönni
Distributed under the Boost Software License, Version 1.0. (See
accompanying file LICENSE_1_0.txt or
copy at http://www.boost.org/LICENSE_1_0.txt)
|