From: stipe_at_[hidden]
Date: 2008-02-05 00:45:42
Author: srajko
Date: 2008-02-05 00:45:40 EST (Tue, 05 Feb 2008)
New Revision: 43110
URL: http://svn.boost.org/trac/boost/changeset/43110
Log:
update docs
Text files modified:
sandbox/SOC/2007/signals/libs/dataflow/doc/dataflow.qbk | 12 +
sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/gui_example.qbk | 9 +
sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/introduction.qbk | 140 +++++++++++++++-----------
sandbox/SOC/2007/signals/libs/dataflow/doc/rationale.qbk | 38 +++---
sandbox/SOC/2007/signals/libs/dataflow/doc/signals.qbk | 32 ------
sandbox/SOC/2007/signals/libs/dataflow/doc/signals/introduction.qbk | 195 +++++++++++++++++++++----------------
sandbox/SOC/2007/signals/libs/dataflow/doc/support/concepts/component.qbk | 68 +++++++++++++
sandbox/SOC/2007/signals/libs/dataflow/doc/support/concepts/concepts.qbk | 152 -----------------------------
sandbox/SOC/2007/signals/libs/dataflow/doc/support/concepts/general.qbk | 174 ++++++++++++++++++++++++++-------
sandbox/SOC/2007/signals/libs/dataflow/doc/support/concepts/port.qbk | 206 +++++++++++----------------------------
sandbox/SOC/2007/signals/libs/dataflow/doc/support/support.qbk | 2
11 files changed, 497 insertions(+), 531 deletions(-)
Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/dataflow.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/dataflow.qbk (original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/dataflow.qbk 2008-02-05 00:45:40 EST (Tue, 05 Feb 2008)
@@ -17,14 +17,15 @@
[template Traits[] [link dataflow.support.concepts.general.entity [^Traits]]]
[template Entity[] [link dataflow.support.concepts.general.entity [^Entity]]]
[template PortCategory[] [link dataflow.support.concepts.port_related.portcategory [^PortCategory]]]
+[template Mechanism[] [link dataflow.support.concepts.port_related.mechanism [^Mechanism]]]
[template PortTraits[] [link dataflow.support.concepts.port_related.port [^PortTraits]]]
[template Port[] [link dataflow.support.concepts.port_related.port [^Port]]]
[template ProducerPort[] [link dataflow.support.concepts.port_related.port [^ProducerPort]]]
[template ConsumerPort[] [link dataflow.support.concepts.port_related.port [^ConsumerPort]]]
[template ComplementedPort[] [link dataflow.support.concepts.port_related.complementedport [^ComplementedPort]]]
[template ComplementedPortTraits[] [link dataflow.support.concepts.port_related.complementedport [^ComplementedPortTraits]]]
-[template PortVector[] [link dataflow.support.concepts.general.portvector [^PortVector]]]
-[template PortVectorTraits[] [link dataflow.support.concepts.general.portvector [^PortVectorTraits]]]
+[template PortVector[] [link dataflow.support.concepts.component.portvector [^PortVector]]]
+[template PortVectorTraits[] [link dataflow.support.concepts.component.portvector [^PortVectorTraits]]]
[template VectorPort[] [link dataflow.support.concepts.port_related.vectorport [^VectorPort]]]
[template VectorPortTraits[] [link dataflow.support.concepts.port_related.vectorport [^VectorPortTraitr]]]
[template KeyedPort[] [link dataflow.support.concepts.port_related.keyedport [^KeyedPort]]]
@@ -119,10 +120,13 @@
[template FuturePin[] [link dataflow.future.pin pin]]
[template rationale[] [link dataflow.development.rationale rationale]]
+[template is_tag[] [classref boost::dataflow::is_tag is_tag]]
+[template is_mechanism[] [classref boost::dataflow::is_mechanism is_mechanism]]
[template is_port_category[] [classref boost::dataflow::is_port_category is_port_category]]
[template port_traits[] [classref boost::dataflow::port_traits [^port_traits]]]
[template traits_of[] [classref boost::dataflow::traits_of traits_of]]
[template register_traits[] [classref boost::dataflow::register_traits register_traits]]
+[template is_entity[] [classref boost::dataflow::is_entity [^is_entity]]]
[template is_port[] [classref boost::dataflow::is_port [^is_port]]]
[template port[] [classref boost::dataflow::port [^port]]]
[template complemented_port_traits[] [classref boost::dataflow::complemented_port_traits [^complemented_port_traits]]]
@@ -130,7 +134,9 @@
[template DATAFLOW_TRAITS[] [macroref DATAFLOW_TRAITS DATAFLOW_TRAITS]]
[template DATAFLOW_TRAITS_ENABLE_IF[] [macroref DATAFLOW_TRAITS_ENABLE_IF DATAFLOW_TRAITS_ENABLE_IF]]
-[template default_tag[] [classref boost::dataflow::default_tag [^concepts::default_tag]]]
+[template default_tag[] [classref boost::dataflow::default_tag [^default_tag]]]
+
+[template true[] Boolean MPL Metafunction that evaulates to true]
[import ../test/test_port.cpp]
Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/gui_example.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/gui_example.qbk (original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/gui_example.qbk 2008-02-05 00:45:40 EST (Tue, 05 Feb 2008)
@@ -11,6 +11,15 @@
[$blueprint_screenshot.png]
+It currently has the following capabilities:
+
+* there is a component bank with 4 hardcoded (but easily extensible) components
+* you can click on a component to add it to the blueprint
+* you can drag the components around
+* you can connect ports that are [Connectable]
+* you can invoke components that are [Invocable]
+* a few of the components have a GUI element which can be interacted with
+
To build the GUI example, you will need to download [FLTK]. At some point
I will probably develop another version for the [cppgui] library being
developed.
Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/introduction.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/introduction.qbk (original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/introduction.qbk 2008-02-05 00:45:40 EST (Tue, 05 Feb 2008)
@@ -6,25 +6,86 @@
as well as some GSoC status updates can be found on the
[@http://svn.boost.org/trac/boost/wiki/soc/2007/SignalNetwork GSoC page].]
-Dataflow is a generic library for [WikiDataflow] programming. It offers:
+[heading Description]
-* a number of generic [concepts] which capture various aspects of a
-dataflow framework.
-* a support layer for a particular dataflow framework ([DataflowSignals]).
-* a framework-independent layer ([DataflowBlueprint]) built on top of the
- generic layer, which
- provides dataflow network modeling/analysis via
- the [BoostGraph], and support for run-time reflection of components.
-
+Dataflow is a generic library for [WikiDataflow] programming. Dataflow
+programs can typically be expressed as a graph in which vertices represent
+components that process data, and edges represent the flow of data between
+the components. As such, dataflow programs can be easily reconfigured by
+changing the components and/or the connections.
+
+[heading Library Layers]
+The Dataflow library currently offers three layers:
+
+* A layer providing generic dataflow support centered around [concepts],
+ adaptable to various dataflow frameworks and data transport mechanisms.
+* The [DataflowSignals] layer, with a number of implemented components use
+ [BoostSignals] as a data transport mechanism.
+* The [DataflowBlueprint] layer, built on top of the generic layer and providing
+ runtime reflection and network modeling using the [BoostGraph].
+
+The relationship of these layers is shown in the following diagram:
+
+[$layers.png]
+
+As indicated by the diagram, classes provided by [DataflowSignals] model
+the concepts from the generic dataflow layer. [DataflowBlueprint] class
+templates require these concepts, hence they can be used with [DataflowSignals].
The idea behind providing a generic dataflow library is that
other data transport mechanisms and dataflow frameworks can be easily adapted for
-use with the library, and benefit from layers built on top of the generic layer.
+use with the library (through modeling the appropriate concepts), and benefit from
+any layers built on top of the generic layer (through requiring the appropriate
+concepts).
+
+[/There is also a (currently very experimental) [DataflowPhoenix] layer,
+which uses object pointers with support for
+[BoostPhoenix] actors specifying how the data is processed.]
+
+[h5 Generic dataflow layer]
+
+The generic dataflow layer provides [concepts] which are applicable to
+different dataflow frameworks, and can be used to develop generic dataflow
+code. Currently, the concepts adress things such as [Component]s and [Port]s,
+as well as the connection and data extraction functionality
+(the [rationale] section discusses why this is the initial focus).
+
+[DataflowSignals] has a (very thin) support layer which makes `boost::signal`
+and `boost::function` model the Dataflow [concepts], and there is an
+[vtk_example example] showing how to do the same for [VTK]. Support layers
+for other dataflow frameworks will be added in the future.
+
+Developing a Dataflow support layer for a dataflow framework allows
+anything that is built on top of the generic layer (e.g., [DataflowBlueprint],
+a [gui_example GUI dataflow editor], and operators which can be used
+to connect components in a clean, readable manner) to be used with the
+framework. See the [link dataflow.future future directions] section
+for an idea of about other things in planning.
+
+[h5 Dataflow.Signals layer]
+
+This part of the Dataflow library provides Dataflow support and processing
+components which use [BoostSignals] as a mechanism to transfer data
+between the components.
+
+[h5 Dataflow.Blueprint layer]
+
+[DataflowBlueprint] provides run-time reflection and modeling of dataflow
+networks in a [BoostGraph] graph for any dataflow framework with
+implemented Dataflow library support.
[/There is an example on how to do that for [VTK], and there is also an
implementation of an (experimental and currently broken) layer based
connections made through simple object pointers, with support for using
[BoostPhoenix2] actors for data processing ([DataflowPhoenix]).]
+[heading What the Dataflow library doesn't offer]
+
+Ideally, the Dataflow library should at some point offer a native dataflow
+framework which offers memory management, flexible scheduling, optimized
+evaluation, etc. At this point, such a framework is missing.
+
+[heading Where to go from here]
+
* If you would like some more information about why one would want to connect
objects into a dataflow network, read about
[link dataflow.introduction.dataflow Dataflow programming in C++].
@@ -186,44 +247,12 @@
[section:how_to_use How to use this library and the documentation]
-The Dataflow library currently has three useful parts:
-
-* A layer providing generic dataflow support, adaptable to various dataflow
- frameworks and data transport mechanisms.
-* The [DataflowSignals] layer, with a number of implemented components that
- facilitate implementation of dataflow networks using [BoostSignals] as
- a data transport mechanism.
-* The [DataflowBlueprint] layer, built on top of the generic layer and providing
- runtime reflection and network modeling using the [BoostGraph].
+Different layers of the library are covered in different sections of the
+documentation. Here are some good starting points for the different layers:
-[/There is also a (currently very experimental) [DataflowPhoenix] layer,
-which uses object pointers with support for
-[BoostPhoenix] actors specifying how the data is processed.]
[heading Generic dataflow layer]
-There are generic properties of dataflow programs which do not depend on the
-underlying dataflow framework or data transport mechanism,
-and can be exploited to develop generic dataflow code. Currently, the generic
-layer addresses mostly connection and extraction aspects - the [rationale]
-section discusses why.
-
-[/The generic dataflow layer captures some of these properties, and
-has been sucessfully adapted to three
-different data transport mechanisms ([BoostSignals], pointers in conjunction
-with [BoostPhoenix2], and [VTK] pipelines).]
-
-At the moment, the most useful functionality gained by developing a Dataflow
-support layer is the ability to connect components in a clean, readable
-manner. As more generic code is developed on top of
-the generic dataflow layer (such as the recently started [DataflowBlueprint]),
-providing a Dataflow support layer for your
-favorite dataflow framework will be more beneficial.
-
-See the [link dataflow.future future directions] section
-for an idea of what might become available in the future for dataflow frameworks
-with Dataflow library support.
-
* If you would like to implement Dataflow support for the dataflow framework
you are working with, see the
[link dataflow.introduction.examples.new_layer example] showing
@@ -233,25 +262,17 @@
[heading Dataflow.Signals layer]
-This part of the Dataflow library provides components
-and connection-making capabilty which facilitates large-scale use of
-[BoostSignals] as a mechanism to transfer data between processing components.
-
For examples of how the [DataflowSignals] layer can be used, see:
-* The example on developing a
+* The example on developing a
[link dataflow.introduction.examples.distributed distributed dataflow application].
-* The example on developing an
+* The example on developing an
[link dataflow.introduction.examples.gil image processing network].
* The [DataflowSignals] documentation.
[heading Dataflow.Blueprint layer]
-[DataflowBlueprint] provides run-time reflection and modeling of dataflow
-networks in a [BoostGraph] graph for any dataflow framework with
-implemented Dataflow library support.
-
-The development of this layer has only begun. To find out more about it, see:
+The development of this layer is ongoing. To find out more about it, see:
* The example on [link dataflow.introduction.examples.blueprint run-time
reflection and connectivity modeling].
@@ -404,7 +425,7 @@
* make dispatching possible on other than just the [PortTraits]
* `port_adapter` should be renamed to `adapter`
* [Invocable] should be a part of [UnaryOperable]
-* propagate return values where they should be
+* propagate return values where they should be propagated
See the [future_work] section for more information on what is planned.
@@ -455,7 +476,7 @@
running bjam.
[warning The Jamfile for the VTK examples currently only works for Darwin
-with VTK built for X11, and for MSVC]
+with VTK built for X11, and for MSVC.]
The library itself is header only, and requires no linking. However, parts
of it depend on boost libraries which do need to be built and linked (see
@@ -464,7 +485,7 @@
[heading Linking]
The generic Dataflow support layer is header-only, and relies only on other
-Boost header-only libraries (MPL, enable_if, and small parts of fusion).
+Boost header-only libraries.
The [DataflowSignals] layer is dependent on the [BoostSignals] library,
which must be built and linked. A few of the components ([socket_sender]
@@ -473,6 +494,9 @@
([mutex] and [condition]) are dependent on [BoostThread], which has to be
linked as well.
+The [vtk_example VTK example] requires [VTK], and the [gui_example GUI dataflow
+editor example] requires [FTLK].
+
[endsect][/download]
[endsect][/introduction]
Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/rationale.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/rationale.qbk (original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/rationale.qbk 2008-02-05 00:45:40 EST (Tue, 05 Feb 2008)
@@ -3,15 +3,15 @@
[heading General focus of the library]
* The generic dataflow layer focuses mostly on connection and extraction
- functionality of a dataflow framework. The reason I started with connection
- and extraction is that it is the single most uniformly present
- aspect of dataflow frameworks (going to the very definition of dataflow).
-
- * Much of current dataflow framework development is dedicated to framework-specific
- visual programming
- environments, and bindings to outside languages. Much of this
- can be done in a generic fashion, given generic support for connecting
- components and extracting data of the Dataflow library.
+ functionality of a dataflow framework, since this functionality should
+ be present in all dataflow frameworks
+ (going to the very definition of dataflow).
+
+ * Generic treatment of component connection and data extraction is useful
+ because, for example, much of current dataflow framework development is
+ dedicated to visual programming environments, and bindings to outside
+ languages. Rather than reinventing the wheel for every framework separately,
+ much of this can be done in a generic fashion instead.
* While there are many other
functionalities that can be part of a dataflow framework (such as memory
@@ -25,16 +25,15 @@
is [DataflowSignals] for three reasons:
* a [BoostSignals]-based framework was the original focus of this project;
+ * [DataflowSignals] uses existing Boost functionality to make
+ the implementation of the dataflow framework extremely simple.
* components in other frameworks (e.g., [VTK]) don't rely exclusively on
- their framework's dataflow mechanisms to do their work
- (e.g., apart from connecting
- [VTK] components and moving data through [VTK]'s pipeline,
- you can also call the components' methods to customize their
- behavior). [BoostSignals], since it is based on function calls, can
- then be used to access function calling behavior in a way that is
- native to the Dataflow library.
- * [DataflowSignals] makes use of existing Boost functionality to make
- the implementation of the dataflow framework extremely simple.
+ their framework's dataflow mechanisms to do their work. For example,
+ apart from connecting [VTK] components and moving data through [VTK]'s
+ pipeline, the user also needs to call the components' methods to customize
+ their behavior). Since [BoostSignals] is based on data transfer through
+ function calls, it can be used to expose [VTK] components' methods
+ in a way that is native to the Dataflow library.
* There is no
doubt that implementing other kinds of dataflow frameworks would be useful
@@ -66,7 +65,8 @@
[heading Implementation choices]
-* Among various tag dispatch conventions, I chose to go with functor templates
+* Among various tag dispatch conventions, I chose to go with function object
+ templates
because of relative simplicity as well as integration with boost::result_of.
Using a function might be another good alternative (as suggested
[@http://www.boost.org/more/generic_programming.html#tag_dispatching here]),
Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/signals.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/signals.qbk (original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/signals.qbk 2008-02-05 00:45:40 EST (Tue, 05 Feb 2008)
@@ -8,36 +8,4 @@
[include signals/components.qbk]
-[/The Signal Network library relies on moving the data via function parameters and return values.
-Here, the Boost.Signals library is used to model these individual data channels which couple
-the data transfer and the computational component invocation. This is one possible dataflow-oriented
-approach.
-
-Each of these approaches has different properties. In the signal-based approach, the knowledge of the
-network is local - each component knows about where its signals are going, but it knows nothing
-of where the signals arriving at its own slots are coming from. Unless we record how the network was
-constructed, there is no "big picture" of what the complete network looks like. Similarly,
-the network is executed autonomously - the components invoke one another when appropriate, and
-no external control mechanism is required.]
-
-
-[BoostSignals] is an excellent building block for dataflow networks,
-as it provides support for all of the essential elements -
-data transport through parameters and return values, combining
-return values from multiple signal calls, component invocation,
-and reconfigurability through connection and disconnection.
-
-The [DataflowSignals] module uses [BoostSignals] as
-the data transport mechanism in dataflow networks.
-In addition, it provides two major contributions that facilitate the
-building of large signals-based dataflow networks:
-
-* Support for a number of types of components (functors, filters,
- member function slot selection), which can be used with
- the generic Dataflow functionality - such as the [connect] function and its
- associated operators which can be
- used to easily connect different kinds of components.
-* A number of generic and specific components which can be extended
- and customized for use in particular dataflow networks.
-
[endsect]
Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/signals/introduction.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/signals/introduction.qbk (original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/signals/introduction.qbk 2008-02-05 00:45:40 EST (Tue, 05 Feb 2008)
@@ -1,91 +1,39 @@
[section Introduction]
-[section:fusion DataflowSignals and Boost.Fusion]
-
-The components in the [DataflowSignals] module are implemented using [fusion]. To use the
-[DataflowSignals] module, you might benefit from the following if you're not familiar with fusion.
-
-[heading Fused vs. unfused]
-A simple C++ function object might look something like this:
-
- struct f
- {
- int operator()(int arg1, int &arg2, const std::string &arg3)
- {
- ...
- }
- }
-
-The thing to note here is that there are three arguments (of types `int`, `int &`, and `const std::string &`
-respectively), and that when the function object is invoked, they are passed separately:
-
- int x;
- std::string s;
- f()(1, x, s);
-
-In the terminology of [fusion], this function object is /unfused/. This is in contrast to a /fused/
-fuction object, which might look like this:
-
- struct fused_f
- {
- int operator()(fusion::vector<int, int &, const std::string &> &args)
- {
- ...
- }
- }
-
-Basically, the difference is that the three arguments from the unfused version are now sent in a single
-fusion container. The benefit is that no matter how many "unfused" arguments there are, there is
-always a single "fused" argument. Hence, writing templates that deal with a variable number of arguments
-becomes a lot simpler.
-
-[heading [DataflowSignals] provides both fused and unfused components]
-
-While writing the generic components provided in the [DataflowSignals] module benefits from using
-[fusion], your particular use case might not. For this reason, every component provided
-by the [DataflowSignals] module:
-
-* can receive both fused and unfused signals
-* has both a version that sends fused signals and a version that sends unfused signals.
-
-The type of sent signal is provided as a template argument to the class, with
-the default value being `unfused`.
-
-For example,
-
- signals::storage<int (int, int &, const std::string &>), signals::unfused> unfused_storage;
- signals::storage<int (int, int &, const std::string &>)> unfused_storage_by_default;
- signals::storage<int (int, int &, const std::string &>), signals::fused> fused_storage;
-
-In the above case, `unfused_storage` is similar to `f` above, and can be used as a slot
-for signals which carry regular, unfused arguments.
-On the other hand, `fused_storage` acts as a function object similar to `fused_f` above.
-Hence, it can be used as a slot for signals which carry a fusion container as an argument.
-
-[heading Examples mostly show unfused versions]
-
-The examples shown in this documentation are mostly focused on the unfused
-versions of the components, since a user starting with the library
-is most likely to be using the library with unfused components.
-In the vast majority of cases, when all of the
-components used are library-provided components, the fused and unfused examples
-are identical except for the specifications that the components should be fused
-or unfused.
-
-The biggest differences come into play when the examples
-include user-implemented components - implementing a fused component can
-be slightly (or greatly) different from implementing an unfused component.
-In these situations, the documentation should state the differences in code
-when using fused components.
-
-[endsect][/fusion]
+[/The Signal Network library relies on moving the data via function parameters and return values.
+Here, the Boost.Signals library is used to model these individual data channels which couple
+the data transfer and the computational component invocation. This is one possible dataflow-oriented
+approach.
+
+Each of these approaches has different properties. In the signal-based approach, the knowledge of the
+network is local - each component knows about where its signals are going, but it knows nothing
+of where the signals arriving at its own slots are coming from. Unless we record how the network was
+constructed, there is no "big picture" of what the complete network looks like. Similarly,
+the network is executed autonomously - the components invoke one another when appropriate, and
+no external control mechanism is required.]
+
+
+[BoostSignals] is an excellent building block for dataflow networks,
+as it provides support for all of the essential elements -
+data transport through parameters and return values, combining
+return values from multiple signal calls, component invocation,
+and reconfigurability through connection and disconnection.
+
+The [DataflowSignals] module uses [BoostSignals] as
+the data transport mechanism in dataflow networks.
+In addition, it provides two major contributions that facilitate the
+building of large signals-based dataflow networks:
+
+* Support for a number of types of components (functors, filters,
+ member function slot selection), which can be used with
+ the generic Dataflow functionality - such as the [connect] function and its
+ associated operators which can be
+ used to easily connect different kinds of components.
+* A number of generic and specific components which can be extended
+ and customized for use in particular dataflow networks.
[section Quick Start]
-[note If you are not familiar with [BoostFusion], you may want to read the
-[link dataflow.introduction.fusion Dataflow.Signals and Boost.Fusion] section
-first.]
-
[DataflowSignals] provides many common building block components for a
signal-based dataflow network. The most basic is [storage], which
can be used to store a value received through a signal, send it on,
@@ -233,4 +181,85 @@
[endsect][/examples]
+[section:fusion DataflowSignals and Boost.Fusion]
+
+The components in the [DataflowSignals] module are implemented using [fusion]. To use the
+[DataflowSignals] module, you might benefit from the following if you're not familiar with fusion.
+
+[heading Fused vs. unfused]
+A simple C++ function object might look something like this:
+
+ struct f
+ {
+ int operator()(int arg1, int &arg2, const std::string &arg3)
+ {
+ ...
+ }
+ }
+
+The thing to note here is that there are three arguments (of types `int`, `int &`, and `const std::string &`
+respectively), and that when the function object is invoked, they are passed separately:
+
+ int x;
+ std::string s;
+ f()(1, x, s);
+
+In the terminology of [fusion], this function object is /unfused/. This is in contrast to a /fused/
+fuction object, which might look like this:
+
+ struct fused_f
+ {
+ int operator()(fusion::vector<int, int &, const std::string &> &args)
+ {
+ ...
+ }
+ }
+
+Basically, the difference is that the three arguments from the unfused version are now sent in a single
+fusion container. The benefit is that no matter how many "unfused" arguments there are, there is
+always a single "fused" argument. Hence, writing templates that deal with a variable number of arguments
+becomes a lot simpler.
+
+[heading [DataflowSignals] provides both fused and unfused components]
+
+While writing the generic components provided in the [DataflowSignals] module benefits from using
+[fusion], your particular use case might not. For this reason, every component provided
+by the [DataflowSignals] module:
+
+* can receive both fused and unfused signals
+* has both a version that sends fused signals and a version that sends unfused signals.
+
+The type of sent signal is provided as a template argument to the class, with
+the default value being `unfused`.
+
+For example,
+
+ signals::storage<int (int, int &, const std::string &>), signals::unfused> unfused_storage;
+ signals::storage<int (int, int &, const std::string &>)> unfused_storage_by_default;
+ signals::storage<int (int, int &, const std::string &>), signals::fused> fused_storage;
+
+In the above case, `unfused_storage` is similar to `f` above, and can be used as a slot
+for signals which carry regular, unfused arguments.
+On the other hand, `fused_storage` acts as a function object similar to `fused_f` above.
+Hence, it can be used as a slot for signals which carry a fusion container as an argument.
+
+[heading Examples mostly show unfused versions]
+
+The examples shown in this documentation are mostly focused on the unfused
+versions of the components, since a user starting with the library
+is most likely to be using the library with unfused components.
+In the vast majority of cases, when all of the
+components used are library-provided components, the fused and unfused examples
+are identical except for the specifications that the components should be fused
+or unfused.
+
+The biggest differences come into play when the examples
+include user-implemented components - implementing a fused component can
+be slightly (or greatly) different from implementing an unfused component.
+In these situations, the documentation should state the differences in code
+when using fused components.
+
+[endsect][/fusion]
+
+
[endsect][/introduction]
Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/support/concepts/component.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/support/concepts/component.qbk (original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/support/concepts/component.qbk 2008-02-05 00:45:40 EST (Tue, 05 Feb 2008)
@@ -1,4 +1,72 @@
+[section:portvector PortVector, PortVectorTraits]
+
+[heading Notation]
+
+[variablelist
+ [[`T`] [A [Tag] type. If omitted, `T` defaults to [default_tag].]]
+ [[PV] [A [PortVector] type.]]
+ [[PVT] [[PortVectorTraits] of `PV` for `T`.]]
+ [[pv] [An object of type `PV`.]]
+ [[I] [An integer in the range \[0, # of [Port]s exposed by `PV`)]]
+ [[IC] [An IntegralConstant with value in the range \[0, # of [Port]s exposed by `PV`)]]
+]
+
+[heading PortVector Requirements]
+[table
+ [[Name] [Expression] [Result Type] [Semantics]]
+ [
+ [PortVector Traits]
+ [`traits_of<>::type`]
+ [`PVT`]
+ [
+ The [ComponentTraits] of the component.
+ ]
+ ]
+ [
+ [ GetPort ]
+ [`get_port_c<M, I>(c)`]
+ []
+ [
+ Returns the I'th [PortVectorTraits] exposed by `C`
+ ]
+ ]
+ [
+ [ GetPort ]
+ [`get_port<M, IC>(c)`]
+ []
+ [
+ Returns the IC'th [PortVectorTraits] exposed by `C`
+ ]
+ ]
+]
+
+[heading PortVectorTraits Requirements]
+[table
+ [[Name] [Expression] [Result Type] [Semantics]]
+ [
+ [Port Traits]
+ [`PVT::ports`]
+ [MPL Sequence of [PortTraits] types]
+ [
+ An enumeration of the [PortTraits] of the exposed
+ [Port]s.
+ ]
+ ]
+]
+
+[heading Header]
+
+The types, templates, and functions shown here are declared in the following
+files:
+
+```
+ #include <boost/dataflow/support.hpp>
+```
+
+[endsect][/portvector]
+
+
[section:component Component, ComponentTraits]
A ['[Component]] is the fundamental data processing element. It can
Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/support/concepts/concepts.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/support/concepts/concepts.qbk (original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/support/concepts/concepts.qbk 2008-02-05 00:45:40 EST (Tue, 05 Feb 2008)
@@ -1,161 +1,9 @@
[section Concepts]
-[/To explore generic dataflow in C++, let us begin by examining where the flow of
-data happens in C++. Rather informally, we can divide things as follows:
-
-* on one hand, there is data (variables, objects, etc...)
-* on the other, there are computational elements (functions, methods, etc...)
-
-Data can then be processed by the computational
-elements by applying the elements to the data in some appropriate way.
-There are several ways of providing data to the computational elements:
-
-* by placing it in a location where the computational element will read it
-* by passing it as a parameter in a call
-* (a combination of the above) by passing the location of the data as a
-parameter in a call
-
-Similarly, there are several ways of getting data out of a computational element:
-
-* the element makes a function call that carries the data as a parameter
-* the element places a value somewhere where it can be read
-* the element returns it as a return value
-
-With the above in mind, let's informally introduce a few concepts related to dataflow
-programming:]
-
-[heading Mechanisms]
-
-There are many different ways of transferring data in a dataflow detwork.
-For example, [BoostSignals] offers transfer of data through function calls,
-while [VTK] offers a number of classes which are meant to be connected in
-a pipline (e.g., starting with the data source, manipulating it, and
-finally displaying it on the screen).
-
-[BoostSignals] and [VTK] are examples of different /mechanisms/ - particular
-ways of performing data transfer. A particular dataflow framework and/or its
-Dataflow library support layer might use one or more mechanisms in its
-implementation.
-
-In the Dataflow library, most port related class templates are keyed through
-a [Tag] type tag. For example, the [DataflowSignals] layer
-uses two mechanisms for its ports and related operations - one mechanism
-is used for lasting connections between a `signal` and a `function`, while
-another is used for one-time extractions of data.
-
-[heading Ports]
-
-The fundamental point of data production or consumption is called a /port/.
-Two complementary ports that produce / consume the same type of data (using
-the same type of mechanism) can typically be connected/disconnected, or data
-can be extracted from one port to another.
-
-Depending on the data-transport mechanism used, a producer port could be anything
-that produces / provides data: a POD variable, an object of a class type, or
-a function that returns a value. Similarly, a consumer port could be anything
-that consumes data - a function that takes an argument, a functor, etc.
-
-Ports are captured more formally by the [Port] concept.
-
-[heading Components]
-
-A /component/ is the fundamental data processing element of a dataflow
-network. It can have multiple ports, for example a video filter component
-might have one consumer port (consuming video to be processed) and one
-producer port (producing filtered video).
-
-Typically, a component is embedded in a class, and the different [Port]s
-are accessible either through the class directly, or through its member
-functions and variables.
-
-The Dataflow library also offers a [Component] concept, which is
-intented to provide compile-time introspection and other operations.
-
-[heading Proxies]
-
-It is often the case that a port delegates its [Port]
-functionality to some other element. For example, a
-class that is a [DataflowSignals] component might delegate its
-producer [Port] functionality to a member boost::signal. It can
-do so by declaring itself a [ProxyProducerPort] for the boost::signal.
-
-[heading Port Operations]
-
-To establish a flow of data in a dataflow program, we typically /connect/
-producers and consumers using some type of /connection/. In C++, this is usually
-done through a pointer-like mechanism. For example, a boost::signal can be used
-by a producer to dissiminate data to multiple consumers which have been
-connected to the signal. Or, a consumer class might have a pointer to a variable
-which it collects data from.
-
-Operations between two ports such as /connect/, /connect_only/, /disconnect/,
-and /extract/ are captured by the [BinaryOperable] concept. Operations
-on a single port such as /disconnect_all/ are covered by the [UnaryOperable]
-concept.
-
-[/
-[heading Push and pull]
-
-Components can be further categorized according to where the connection lies,
-and what it points to. If the producer contains the connection(s) which point
-to the consumer(s) (say, a `boost::signal<void (int)>`), the producer is called a
-/push producer/. If the consumer contains the connection(s) which point to the
-producer(s), the consumer is called a /pull consumer/. A connection
-between a push producer and a (non-pull) consumer is a /push connection/,
-and a connection between a pull consumer and a (non-push) producer is a
-/pull connection/.
-
-Sometimes things get a little fuzzy - for example, a function
-call can be used to transmit data through the arguments from the caller to the
-callee. However, the callee can transmit data back to the caller by returning
-it. Hence, an object which contains a boost::signal could be both a push
-producer (which sends data through the signal argument) and a pull consumer
-(which receives data through the signal return type). If both directions
-are being used to transmit data, a connection like this is called a /push and
-pull connection/.
-
-It is also possible that the producer points to the consumer and vice versa.
-In this case, the connection is called a /bidirectional connection/.]
-
-[heading Invocation]
-
-[/Another important thing to note is that there is a separation between providing
-the data to a component, and invoking the component. In some cases, the two
-happen simultaneously (when the data is passed and returned via a function
-call), while in others invoking the computational element can happen
-separately from providing the data (at least from a modeling perspective).
-An example of the latter is a consumer which uses data stored in
-a particular location. We can place the data in that location much before
-invoking the consumer.]
-
-We will call /invoking/ a component (producer or consumer) the action of
-causing it to consume data from connected producers, and producing data
-for connected consumers.
-
-Invocation is captured more formally by the [Invocable] concept.
-
[include general.qbk]
[section Port related]
-[section Mechanism]
-
-[note The Mechanism concept currently has no requirements.]
-
-A Mechanism type is used to specify the mechanism when specializing or invoking
-port-related Dataflow templates. Each mechanism therefore has a corresponding
-type tag.
-
-[heading Examples]
-
-The following code declares the [VTK] mechanism tag - it is a part of
-the [vtk_example example showing how to provide a VTK support layer].
-
-[vtk_tag]
-
-[endsect][/mechanism]
-
-
[include port.qbk]
[include binary_operable.qbk]
Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/support/concepts/general.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/support/concepts/general.qbk (original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/support/concepts/general.qbk 2008-02-05 00:45:40 EST (Tue, 05 Feb 2008)
@@ -1,81 +1,111 @@
[section:general General]
-[section:entity Entity,Traits]
+[section:tag Tag]
+
+A [Tag] type is typically used as a template parameter in (most) generic support
+layer templates to specify a particular dataflow framework. This
+allows different dataflow frameworks to be defined on the same types without
+clashing. If clashing is not a concern when developing a support layer
+for a framework, the [Tag] can be omitted in which case it defaults to
+[default_tag].
[heading Notation]
[variablelist
- [[T] [A [Traits] type.]]
+ [[T] [A [Tag] type.]]
]
[heading Requirements]
[table
+ [[Name] [Expression] [Result Type] [Semantics]]
+ [
+ [ default_tag Inheritance]
+ [`is_base<default_tag, T>::type`]
+ [ [true] ]
+ [
+ To allow concept checking on [Tag] types, all [Tag] types
+ must be derived from [default_tag].
+ ]
+ ]
+ [
+ [Tag Concept Check]
+ [[^[is_tag]<T>::type]]
+ [ [true] ]
+ [
+ Concept check for the [Tag] concept.
+ ]
+ ]
]
-[heading Header]
+[heading Examples]
-The types, templates, and functions shown here are declared in the following
-files:
+The following code declares the [VTK] framework [Tag] - it is a part of
+the [vtk_example example showing how to provide a VTK support layer].
-```
- #include <boost/dataflow/support.hpp>
-```
+[vtk_tag]
+
+[endsect]
-[endsect][/entity]
-[section:portvector PortVector, PortVectorTraits]
+[section:entity Entity,Traits]
+
+[Entity] is a base concept for [Port]s and [Component]s. Every [Entity]
+has an associated [Traits] type which describes it's dataflow properties.
+The examples below show how [Traits] can be registered for an [Entity].
+
+The registration of an [Entity] with a [Traits] is always for a specific [Tag].
+Hence, a type is an [Entity] only relative to a [Tag], and can have different
+[Traits] for different [Tag]s.
+
+[heading Refinements]
+
+* [Port], [PortTraits]
+* [Component], [ComponentTraits]
[heading Notation]
[variablelist
[[`T`] [A [Tag] type. If omitted, `T` defaults to [default_tag].]]
- [[PV] [A [PortVector] type.]]
- [[PVT] [[PortVectorTraits] of `PV` for `T`.]]
- [[pv] [An object of type `PV`.]]
- [[I] [An integer in the range \[0, # of [Port]s exposed by `PV`)]]
- [[IC] [An IntegralConstant with value in the range \[0, # of [Port]s exposed by `PV`)]]
+ [[`E`] [An [Entity] type, for [Tag] `T`.]]
+ [[`ET`] [[Traits] of `E` for [Tag] `T`.]]
+ [[`e`] [An object of type `E`]]
]
-[heading PortVector Requirements]
+[heading Entity Requirements]
[table
[[Name] [Expression] [Result Type] [Semantics]]
[
- [PortVector Traits]
- [`traits_of<>::type`]
- [`PVT`]
+ [Entity Traits]
+ [[^[traits_of]<E, T>::type]]
+ [`ET`]
[
- The [ComponentTraits] of the component.
+ The [Traits] of [Entity] `E` for [Tag] `T`.
]
]
[
- [ GetPort ]
- [`get_port_c<M, I>(c)`]
- []
+ [Entity Concept Check]
+ [[^[is_entity]<E, T>::type]]
+ [[true]]
[
- Returns the I'th [PortVectorTraits] exposed by `C`
- ]
- ]
- [
- [ GetPort ]
- [`get_port<M, IC>(c)`]
- []
- [
- Returns the IC'th [PortVectorTraits] exposed by `C`
+ Concept check for the [Entity] concept.
]
]
]
-[heading PortVectorTraits Requirements]
+[heading Traits Requirements]
[table
[[Name] [Expression] [Result Type] [Semantics]]
[
- [Port Traits]
- [`PVT::ports`]
- [MPL Sequence of [PortTraits] types]
+ [Tag]
+ [`ET::tag`]
+ [`T`]
[
- An enumeration of the [PortTraits] of the exposed
- [Port]s.
+ The [Tag] for `ET`.
+[/ Although this currently must be `T`,
+ in the future this might be permitted to be any [Tag] type
+ (and used only in some forms of registration of [Traits]
+ for [Entity]s).]
]
]
]
@@ -89,7 +119,73 @@
#include <boost/dataflow/support.hpp>
```
-[endsect][/entity]
+[heading Notes]
+
+There is an intrusive as well as a non-intrusive way to register the
+[Traits] of a type `E`, thereby making it an [Entity].
+
+Non-intrusive registration is typically done by providing a specialization of
+the [register_traits] template (either directly, or through the provided
+macros [DATAFLOW_TRAITS] and [DATAFLOW_TRAITS_ENABLE_IF]). This will
+specialize [traits_of] for all cv-qualified versions of type `E`.
+If cv-qualified versions of type `E` should have different [Traits]s,
+[traits_of] should be specialized directly.
+
+Intrusive registration can be done by providing
+a `E::dataflow_traits` member type, which can be either a [Traits]
+type, or an MPL sequence of [Traits] types. Alternatively,
+the Dataflow library provides a convenience class
+`entity` which you can inherit instead of declaring the member type. This
+provides the additional benefit of accessing the free functions in the
+`boost::dataflow` namespace using ADL.
+
+The below examples illustrate the avaliable registration methods.
+
+[heading Examples]
+
+All of the below examples use the following [Tag] and
+[Traits] types:
+
+[port_registration_example_prep]
+
+[heading Intrusive registration]
+
+Intrusive registration is the easiest, but assumes you can modify the
+[Entity]:
+
+[port_registration_example_intrusive]
+
+[heading Non-intrusive registration]
+Non-intrusive registration is done by specializing the `register_traits`
+template. Since the `register_traits` template is keyed by [Tag],
+this is rather verbose:
+
+[port_registration_example_non_intrusive]
+
+To make things simpler, the Dataflow library provides a macro for non-intrusive
+registration (the macro also performs a static concept check on the
+[Traits]).
+
+[port_registration_example_non_intrusive_macro]
+
+[heading Non-intrusive mass registration]
+
+The [register_traits] template has an Enable template parameter for use with
+`boost::enable_if`. Hence, we can register a number of types at the same time:
+
+[port_registration_example_non_intrusive_enable_if]
+
+And again, there is a convenient macro:
+
+[port_registration_example_non_intrusive_enable_if_macro]
+
+[heading Tests]
+
+With the above registrations, the following tests pass:
+
+[port_registration_check_example]
+
+[endsect][/entity]
[endsect]
Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/support/concepts/port.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/support/concepts/port.qbk (original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/support/concepts/port.qbk 2008-02-05 00:45:40 EST (Tue, 05 Feb 2008)
@@ -1,13 +1,11 @@
[section PortCategory]
-A [PortCategory] designates a category of port in the Dataflow library.
+A [PortCategory] designates a category of [Port] in the Dataflow library.
The library currently defines two [PortCategory]s:
* `boost::dataflow::ports::producer`, and
* `boost::dataflow::ports::consumer`.
-For a higher-level overview of the concepts, see the [concepts] introduction.
-
[heading Notation]
The following expressions are used in this document:
@@ -31,11 +29,11 @@
]
]
[
- [Is PortCategory Trait]
+ [PortCategory Concept Check]
[[^[is_port_category]<T>::type]]
- [Boolean MPL Metafunction that evaulates to true]
+ [[true]]
[
- Trait encapsulating adherence to the [PortCategory] concept.
+ Concept check for the [PortCategory] concept.
]
]
]
@@ -52,22 +50,54 @@
[endsect][/portcategory]
+[section:mechanism Mechanism]
+
+A [Mechanism] type is used to select a default port.
+
+[heading Notation]
+
+[variablelist
+ [[M] [A [Mechanism] type.]]
+]
+
+[heading Requirements]
+
+[table
+ [[Name] [Expression] [Result Type] [Semantics]]
+ [
+ [default_mechanism Inheritance]
+ [`is_base<default_mechanism, M>::type`]
+ [ [true] ]
+ [
+ To allow concept checking on [Mechanism] types, all [Mechanism] types
+ must be derived from default_mechanism.
+ ]
+ ]
+ [
+ [Mechanism Concept Check]
+ [[^[is_mechanism]<T>::type]]
+ [ [true] ]
+ [
+ Concept check for the [Mechanism] concept.
+ ]
+ ]
+]
+
+[endsect]
+
+
[section:port Port, PortTraits]
A ['[Port]] is the fundamental point of data production or consumption.
-In order for a type `P` to satisfy the [Port] concept requirements,
-a [PortTraits] type (specifying the traits of the port)
-must be registered for the port. Registration can be
-performed in multiple ways (see the examples below).
-
-[Port] concept
-requirements are always relative to a particular [Tag], so a type
-can be a [Port] for multiple [Tag]s.
-[heading Port Refinements]
+[heading Refinement of]
+* [Entity], [Traits]
+
+[heading Refinements]
-* [KeyedPort]
* [ComplementedPort]
+* [VectorPort]
+* [KeyedPort]
[heading Notation]
The following expressions are used in this document:
@@ -75,12 +105,16 @@
[variablelist
[[`T`] [A [Tag] type. If omitted, `T` defaults to [default_tag].]]
[[`PC`] [A [PortCategory] type.]]
+ [[`M`] [A [Mechanism] type.]]
[[`P`] [A Port type, for [Tag] `T`.]]
[[`PT`] [[PortTraits] of `P` for `T`.]]
[[`p`] [An object of type `P`]]
]
[heading Port Requirements]
+The requirements are listed only when different or in addition to [Entity]
+requirements.
+
[table
[[Name] [Expression] [Result Type] [Semantics]]
[
@@ -88,16 +122,15 @@
[[^[traits_of]<P, T>::type]]
[`PT`]
[
- The [PortTraits] of the port.
+ The [PortTraits] of the [Port].
]
]
[
- [IsPort Trait]
+ [Port Concept Check]
[[^[is_port]<P, T>::type]]
- [Boolean metafunction that evaluates to true]
+ [[true]]
[
- A trait encapsulating adherence to the Port
- concept.
+ Concept check for the [Port] concept.
]
]
[
@@ -111,6 +144,10 @@
]
[heading PortTraits Requirements]
+
+The requirements are listed only when different or in addition to [Traits]
+requirements.
+
[table
[[Name] [Expression] [Result Type] [Semantics]]
[
@@ -119,18 +156,6 @@
[[PortCategory] type]
[The category of the port]
]
- [
- [Port ]
- [`PT::concept`]
- [`concepts::port`, `concepts::keyed_port`, `concepts::complemented_port`]
- [The most refined producer concept that `P` satisfies.]
- ]
- [
- [Tag]
- [`PT::tag`]
- [any type]
- [[Tag] type tag.]
- ]
]
[heading Header]
@@ -146,73 +171,6 @@
* [port]
* [port_traits]
-[heading Notes]
-
-There is an intrusive as well as a non-intrusive way to register the
-[PortTraits] of a type `P`, thereby making it a [Port].
-
-Non-intrusive registration is typically done by providing a specialization of
-the [register_traits] template (either directly, or through the provided
-macros [DATAFLOW_TRAITS] and [DATAFLOW_TRAITS_ENABLE_IF]). This will
-specialize [traits_of] for all cv-qualified versions of type `P`.
-If cv-qualified versions of type `P` should have different [PortTraits]s,
-[traits_of] should be specialized directly.
-
-Intrusive registration can be done by providing
-a `P::port_traits` member type, which can be either a [PortTraits]
-type, or an MPL sequence of [PortTraits] types. Alternatively,
-the Dataflow library provides a convenience class
-`port` which you can inherit instead of declaring the member type. This
-provides the additional benefit of using the free functions in the
-`boost::dataflow` namespace using ADL.
-
-The below examples illustrate the avaliable registration methods.
-
-[heading Examples]
-
-All of the below examples use the following [Tag] and
-[PortTraits] types:
-
-[port_registration_example_prep]
-
-[heading Intrusive registration]
-
-Intrusive registration is the easiest, but assumes you can modify the
-[Port]:
-
-[port_registration_example_intrusive]
-
-[heading Non-intrusive registration]
-
-Non-intrusive registration is done by specializing the `register_traits`
-template. Since the `register_traits` template is keyed by [Tag]
-and [PortCategory], this is rather verbose:
-
-[port_registration_example_non_intrusive]
-
-To make things simpler, the Dataflow library provides a macro for non-intrusive
-registration (the macro also performs a static check on the
-[PortTraits]).
-
-[port_registration_example_non_intrusive_macro]
-
-[heading Non-intrusive mass registration]
-
-The [register_traits] template has an Enable template parameter for use with
-`boost::enable_if`. Hence, we can register a number of types at the same time:
-
-[port_registration_example_non_intrusive_enable_if]
-
-And again, there is a convenient macro:
-
-[port_registration_example_non_intrusive_enable_if_macro]
-
-[heading Tests]
-
-With the above registrations, the following tests pass:
-
-[port_registration_check_example]
-
[endsect][/port]
@@ -220,7 +178,8 @@
A ComplementedPort `P` is a [Port] s.t. whenever it is
[BinaryOperable] with another [Port] `P2`, `P2` is
-a particular type - `P`'s complement type.
+a particular type - either `P`'s complement type, or a [KeyedPort]
+that delegates to `P`'s complement type in a binary operation with `P`.
[ComplementedPort]s are useful in situations where [Port] types
are [BinaryOperable] in a one-to-one fashion (a pair of [Port] types
@@ -316,48 +275,5 @@
[endsect][/keyed_port]
-[section ProxyPort, ProxyPortTraits]
-
-A type `PP` is a ['[ProxyPort]] for a mechanism `M` and port category `PC`
-if it specifies a [ProxyPortTraits] for that mechanism and port category.
-
-If the proxied port type is a valid
-[Port], then 'PP' satisfies the [Port] requirements
-in the same way.
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
- [[PP] [A ProxyPort type.]]
- [[pp] [An object of type `PP`]]
-]
-
-[heading Requirements]
-[table
- [[Name] [Expression] [Result Type] [Semantics]]
- [
- [Proxy Port Traits]
- [`proxy_traits_of<PP>::type`]
- [[ProxyPortTraits] type.]
- [
- The traits of the proxy port.
- ]
- ]
-]
-
-[heading Header]
-The types, templates, and functions shown here are declared in the following
-files:
-
-```
- #include <boost/dataflow/support/proxy_port.hpp> // or
- #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/proxyport]
+
Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/support/support.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/support/support.qbk (original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/support/support.qbk 2008-02-05 00:45:40 EST (Tue, 05 Feb 2008)
@@ -1,5 +1,7 @@
[section:support Generic Support Layer]
+[include introduction.qbk]
+
[include concepts/concepts.qbk]
[xinclude ../dataflow_support_doxygen.xml]