[clang-format] Comply to Google style.

.clang-format

+---
+ColumnLimit:     80
+...

doc/additionalDoc/debug-doc.h

 /**
 \page debug Debugging
 
-They are several ways to perform debugging in dynamic-graph depending on your needs or situation:
-- Programmatically inside the entity in C++ will write inside a buffer in a different thread and output in a stream
-(either std::cout or a file). It is detailed in \subpage subp_debug_rt_logger.
-- Programmatically inside the entity in C++ using a member of the entities and the previous real-time mechanism.
-It provides 4 levels of messags :(DEBUG,INFO, WARNING, ERROR). It is described in details here:
-\subpage subp_logger
-- Programmatically in C++ to avoid overhead with macros and handling level as an int: \subpage subp_dbg_trace
-- If you just need to collect informations from signals (like rosbag). You can use
-an entity called Tracer inside the graph:\subpage tracerdoc . <br>
-A real time version exists
-to write directly inside a memory buffer \subpage tracerrealtimedoc
+They are several ways to perform debugging in dynamic-graph depending on your
+needs or situation:
+- Programmatically inside the entity in C++ will write inside a buffer in a
+different thread and output in a stream (either std::cout or a file). It is
+detailed in \subpage subp_debug_rt_logger.
+- Programmatically inside the entity in C++ using a member of the entities and
+the previous real-time mechanism. It provides 4 levels of messags :(DEBUG,INFO,
+WARNING, ERROR). It is described in details here: \subpage subp_logger
+- Programmatically in C++ to avoid overhead with macros and handling level as an
+int: \subpage subp_dbg_trace
+- If you just need to collect informations from signals (like rosbag). You can
+use an entity called Tracer inside the graph:\subpage tracerdoc . <br> A real
+time version exists to write directly inside a memory buffer \subpage
+tracerrealtimedoc
 **/

doc/additionalDoc/debug-logger.h

@@ -8,8 +8,8 @@
 In order to activate the logger you need to add the following lines:
 \code
 #define ENABLE_RT_LOG
-#include <dynamic-graph/real-time-logger.h>
 #include <dynamic-graph/logger.h>
+#include <dynamic-graph/real-time-logger.h>
 \endcode
 
 \subsection subsec_logger_ Initialize the output stream
@@ -39,14 +39,16 @@ The second line specifies at which frequency the STREAM messages should be
 printed.<br>
 The third line specifies the level of message to accept.<br>
 The fourth line returns the level of verbosity.
-In this case, all messages are accepted and the STREAM message are displayed on the output streams once on five. <br>
+In this case, all messages are accepted and the STREAM message are displayed on
+the output streams once on five. <br>
 
 The full list of options are:
 <ul>
 <li>VERBOSITY_ALL: Accept all messages</li>
-<li>VERBOSITY_INFO_WARNING_ERROR: Accept messages at minimum level : INFO, WARNING, ERROR</li>
-<li>VERBOSITY_WARNING_ERROR: Accept messages at minimum level : WARNING, ERROR</li>
-<li>VERBOSITY_ERROR: Accept messages at minimum level : ERROR</li>
+<li>VERBOSITY_INFO_WARNING_ERROR: Accept messages at minimum level : INFO,
+WARNING, ERROR</li> <li>VERBOSITY_WARNING_ERROR: Accept messages at minimum
+level : WARNING, ERROR</li> <li>VERBOSITY_ERROR: Accept messages at minimum
+level : ERROR</li>
 </ul>
 
 
@@ -54,19 +56,23 @@ The full list of options are:
 
 Here is some example on how to display or record some information.
 \code
-      sendMsg("This is a message of level MSG_TYPE_DEBUG",MSG_TYPE_DEBUG, __FILE__,__LINE__);
-      sendMsg("This is a message of level MSG_TYPE_INFO",MSG_TYPE_INFO, __FILE__,__LINE__);
-      sendMsg("This is a message of level MSG_TYPE_WARNING",MSG_TYPE_WARNING, __FILE__,__LINE__);
-      sendMsg("This is a message of level MSG_TYPE_ERROR",MSG_TYPE_ERROR, __FILE__,__LINE__);
-      sendMsg("This is a message of level MSG_TYPE_DEBUG_STREAM",MSG_TYPE_DEBUG_STREAM, __FILE__,__LINE__);
-      sendMsg("This is a message of level MSG_TYPE_INFO_STREAM",MSG_TYPE_INFO_STREAM, __FILE__,__LINE__);
-      sendMsg("This is a message of level MSG_TYPE_WARNING_STREAM",MSG_TYPE_WARNING_STREAM, __FILE__,__LINE__);
-      sendMsg("This is a message of level MSG_TYPE_ERROR_STREAM",MSG_TYPE_ERROR_STREAM, __FILE__,__LINE__);
+      sendMsg("This is a message of level MSG_TYPE_DEBUG",MSG_TYPE_DEBUG,
+__FILE__,__LINE__); sendMsg("This is a message of level
+MSG_TYPE_INFO",MSG_TYPE_INFO, __FILE__,__LINE__); sendMsg("This is a message of
+level MSG_TYPE_WARNING",MSG_TYPE_WARNING, __FILE__,__LINE__); sendMsg("This is a
+message of level MSG_TYPE_ERROR",MSG_TYPE_ERROR, __FILE__,__LINE__);
+      sendMsg("This is a message of level
+MSG_TYPE_DEBUG_STREAM",MSG_TYPE_DEBUG_STREAM, __FILE__,__LINE__); sendMsg("This
+is a message of level MSG_TYPE_INFO_STREAM",MSG_TYPE_INFO_STREAM,
+__FILE__,__LINE__); sendMsg("This is a message of level
+MSG_TYPE_WARNING_STREAM",MSG_TYPE_WARNING_STREAM, __FILE__,__LINE__);
+      sendMsg("This is a message of level
+MSG_TYPE_ERROR_STREAM",MSG_TYPE_ERROR_STREAM, __FILE__,__LINE__);
 
       logger_.countdown();
 \endcode
 
-Specifying the file with __FILE__ and the line inside the file by __LINE__ are necessary for the
-STREAM messages. Indeed they are indexed using the two values. As the default value are "" and 0
-the counting will be confused.
+Specifying the file with __FILE__ and the line inside the file by __LINE__ are
+necessary for the STREAM messages. Indeed they are indexed using the two values.
+As the default value are "" and 0 the counting will be confused.
 */

doc/additionalDoc/debug-trace-doc.h

@@ -3,10 +3,10 @@
 
 \section subp_dbg_trace_intro Introduction
 The idea of this class and collection of MACROS is to specify
-a level for a message, and record the message in a stream according to this level.
-In addition there are mechanisms allowing that no time
-is wasted in condition test. You can therefore let the debugging messages
-inside the code without impact on performances.
+a level for a message, and record the message in a stream according to this
+level. In addition there are mechanisms allowing that no time is wasted in
+condition test. You can therefore let the debugging messages inside the code
+without impact on performances.
 
 \section subp_dbg_trace_set_on_macros Setting up dgDEBUG macros
 
@@ -31,12 +31,9 @@ are written is specified by:
 
 \section subp_dbg_trace_using_macros Using dgDEBUG macros
 
-To print that the beginning of a method is being executed use the following macros:
-\code
-    dgDEBUGIN(5);
-\endcode
-5 here specifies the minimum level that you be specified by VP_DEBUG_MODE for this message
-to be displayed.
+To print that the beginning of a method is being executed use the following
+macros: \code dgDEBUGIN(5); \endcode 5 here specifies the minimum level that you
+be specified by VP_DEBUG_MODE for this message to be displayed.
 
 It will generate the following output:
 \code
@@ -62,8 +59,8 @@ A message inside the code is written through:
 
 This generates the following output:
 \code
-/path_to/dynamic-graph/tests/debug-trace.cpp: testDebugTrace(#52) :Here is a test
-\endcode
+/path_to/dynamic-graph/tests/debug-trace.cpp: testDebugTrace(#52) :Here is a
+test \endcode
 
 \section subp_dbg_trace_wrk_exp Working example
 

doc/additionalDoc/entity.h

@@ -5,45 +5,57 @@
 \subsection entity_definition General definition
 \image html entity.png
 
-Despite the fact that it looks very similar to a ROS node or a CORBA/OpenRTM server, an entity is simply a C++ object.
-The main idea is that this entity is providing mostly a data-driven functionnality working at very high rate (\f$ 200
+Despite the fact that it looks very similar to a ROS node or a CORBA/OpenRTM
+server, an entity is simply a C++ object. The main idea is that this entity is
+providing mostly a data-driven functionnality working at very high rate (\f$ 200
 Hz\f$ or \f$ 1 kHz \f$) and should have a minimal computational time foot-print.
 
-For this \subpage subp_signals (or ports to use a more classical terminology) are providing a time dependency between
-data. To implement this, an output signal is linked with a method of the entity. The method calls input signals or use
-other means to get the needed data. It might be provided by the connection with remote computers through a middleware,
-or specific protocols, but in general the external data is based upon the sensor values provided by a "Device" entity.
-For this reason the signal evaluations are realized through the cascade of dependencies and start from the evaluation
-of an input signal of a periodic node (in general the device). This is realized inside a \b real-time thread.
-
-To add flexibility to a node, it is possible to add command with arguments to modify the internal behavior of the
-entity or get information from the entity. As a command is in general asynchronous and rare with respect to the
-data-flow scheme for the signals the command is in general executed in a \b none-real-time thread.
+For this \subpage subp_signals (or ports to use a more classical terminology)
+are providing a time dependency between data. To implement this, an output
+signal is linked with a method of the entity. The method calls input signals or
+use other means to get the needed data. It might be provided by the connection
+with remote computers through a middleware, or specific protocols, but in
+general the external data is based upon the sensor values provided by a "Device"
+entity. For this reason the signal evaluations are realized through the cascade
+of dependencies and start from the evaluation of an input signal of a periodic
+node (in general the device). This is realized inside a \b real-time thread.
+
+To add flexibility to a node, it is possible to add command with arguments to
+modify the internal behavior of the entity or get information from the entity.
+As a command is in general asynchronous and rare with respect to the data-flow
+scheme for the signals the command is in general executed in a \b none-real-time
+thread.
 
 \subsection entity_classes Entity class
-Entities are implemented as C++ classes and compiled as dynamic libraries. They can be loaded and instancied
-dynamically. It is therefore necessary to specify the location of their dynamical libraries. However given the time it
-might take to load the library, it is not advised to do that during a control-law computation. Entity instanciation
-also implies memory allocation which is also time consuming and thus not advised inside a real-time thread.
+Entities are implemented as C++ classes and compiled as dynamic libraries. They
+can be loaded and instancied dynamically. It is therefore necessary to specify
+the location of their dynamical libraries. However given the time it might take
+to load the library, it is not advised to do that during a control-law
+computation. Entity instanciation also implies memory allocation which is also
+time consuming and thus not advised inside a real-time thread.
 
-The entities will be placed in ${PREFIX}/lib/plugin (since this may change, it is advised to
-check the install log or the CMakeLists.txt file to check the installation path).
+The entities will be placed in ${PREFIX}/lib/plugin (since this may change, it
+is advised to check the install log or the CMakeLists.txt file to check the
+installation path).
 
 \subsection entities List of entities in this package
 Since most of the functionality in projects using the dynamic-graph framework
-is exposed from entities, here is a short description of all the entities contained in
-this package. Note that most entities are contained in a binary file that closely matches
-the entities' names in the scripts; loading this file with the plugin loader will
-enable creation of this entity through the factory.
+is exposed from entities, here is a short description of all the entities
+contained in this package. Note that most entities are contained in a binary
+file that closely matches the entities' names in the scripts; loading this file
+with the plugin loader will enable creation of this entity through the factory.
 \li \ref tracerdoc
 \li \ref tracerrealtimedoc
 
 \subsection specific_semantics Specific semantics with entities
 
-It is possible to derive classes and apply specific semantic for the entities. In our case we are interested in
-specific control semantics: \li Tasks (more information <a
-href="http://stack-of-tasks.github.io/sot-core/doxygen/HEAD/a00089.html">here</a>) \li Features (more information <a
-href="http://stack-of-tasks.github.io/sot-core/doxygen/HEAD/a00030.html">here</a>) \li Solver (more information <a
+It is possible to derive classes and apply specific semantic for the entities.
+In our case we are interested in specific control semantics: \li Tasks (more
+information <a
+href="http://stack-of-tasks.github.io/sot-core/doxygen/HEAD/a00089.html">here</a>)
+\li Features (more information <a
+href="http://stack-of-tasks.github.io/sot-core/doxygen/HEAD/a00030.html">here</a>)
+\li Solver (more information <a
 href="http://stack-of-tasks.github.io/sot-core/doxygen/HEAD/a00078.html">here</a>)
 
 */

doc/additionalDoc/extension.h

@@ -5,21 +5,24 @@
 
 \subsection use_programmatically General introduction
 
-For control purposes the main use of this package is to create new entities and connect them through signals.
+For control purposes the main use of this package is to create new entities and
+connect them through signals.
 
-Objects, which are derived from Entities (base class dynamicgraph::Entity), can be
-declared within the code and compiled as shared libraries (.so/.dll files).
+Objects, which are derived from Entities (base class dynamicgraph::Entity), can
+be declared within the code and compiled as shared libraries (.so/.dll files).
 These libraries can be loaded at run-time using the PluginLoader methods,
 and at the same time register their class names to the Factory (see the
-examples in the <a href="http://projects.laas.fr/gepetto/doc/stack-of-tasks/sot-core/master/doxygen-html">sot-core
+examples in the <a
+href="http://projects.laas.fr/gepetto/doc/stack-of-tasks/sot-core/master/doxygen-html">sot-core
 documentation</a> for advanced control examples).
 
 The Factory can then create instances of these objects and subsequently
-register them in the Pool. From the pool they can be listed, accessed, and acted upon
-(see PoolStorage documentation). Basic commands defined by entities include
+register them in the Pool. From the pool they can be listed, accessed, and acted
+upon (see PoolStorage documentation). Basic commands defined by entities include
 signal connection graph file generation, help and name print, and signals.
 This is usually done through a scripting language such as python (see
-<a hef="https://github.com/stack-of-tasks/dynamic-graph-python">dynamic-graph-python</a>)
+<a
+hef="https://github.com/stack-of-tasks/dynamic-graph-python">dynamic-graph-python</a>)
 
 The singletons made available by including the corresponding headers in this
 module are:
@@ -30,13 +33,15 @@ For an example of a program creating entities in C++, see the unit test
 test_pool.cpp (in your package source directory/tests).
 
 \subsection Tutorial
-A tutorial is available <a href="http://stack-of-tasks.github.io/dynamic-graph-tutorial/">here</a>.
-It is providing a step-by-step way of building an entity
+A tutorial is available <a
+href="http://stack-of-tasks.github.io/dynamic-graph-tutorial/">here</a>. It is
+providing a step-by-step way of building an entity
 
 \section sec_htw_helpers Helpers
 
 
-When writing entities you might use some macros which are very useful to write your class.
+When writing entities you might use some macros which are very useful to write
+your class.
 
 \subsection subsec_howto_typedef Entity helpers
 
@@ -48,13 +53,13 @@ The header <b>entity-helper.h</b> is defining a type called EntityClassName
 
 <ul>
   <li> <b>DYNAMIC_GRAPH_ENTITY_DECL()</b>:
-  This macro creates a method <b>getClassName()</b> which returns the class name.</li>
-  This macro <b>should</b> be used in the declaration of the class.
+  This macro creates a method <b>getClassName()</b> which returns the class
+name.</li> This macro <b>should</b> be used in the declaration of the class.
   </li>
   <li> <b>DYNAMICGRAPH_FACTORY_ENTITY_PLUGIN(classtype,classname)</b>
-  This macros creates the methods necessary to have a factory building the C++ class
-  <b>classtype</b> from the string <b>classname</b>.
-  This macro <b>should</b> be used in the implementation of the class.
+  This macros creates the methods necessary to have a factory building the C++
+class <b>classtype</b> from the string <b>classname</b>. This macro
+<b>should</b> be used in the implementation of the class.
   </li>
 </ul>
 
@@ -64,15 +69,12 @@ The header <b>entity-helper.h</b> is defining a type called EntityClassName
   <li>  Macro for input signals
     <ul>
       <li> <b>DECLARE_SIGNAL_IN(signal_name,type)</b>:
-      Declare an input time dependent signal as a field of the class with the following name:
-      \code
-      m_signal_nameSIN
-      \endcode
+      Declare an input time dependent signal as a field of the class with the
+following name: \code m_signal_nameSIN \endcode
       </li>
       <li> <b>CONSTRUCT_SIGNAL_IN(signal_name,type)</b>:
-      This macro is used in the constructor of the entity class handling this signal.
-      It is calling the signal constructor and set the signal name to:
-      \code
+      This macro is used in the constructor of the entity class handling this
+signal. It is calling the signal constructor and set the signal name to: \code
       EntityClassName(entity-name)::input(type)::signal_name
       \endcode
     </ul>
@@ -80,32 +82,24 @@ The header <b>entity-helper.h</b> is defining a type called EntityClassName
   <li>  Macro for output signals
     <ul>
       <li> <b>DECLARE_SIGNAL_OUT(signal_name,type)</b>:
-      Declare an output time dependent signal as a field of the class with the following name:
-      \code
-      m_signal_nameSOUT
-      \endcode
-      It also declares a method with the following pattern:
-      \code
-      type signal_nameSOUT_function(type &,int)
-      \endcode
+      Declare an output time dependent signal as a field of the class with the
+following name: \code m_signal_nameSOUT \endcode It also declares a method with
+the following pattern: \code type signal_nameSOUT_function(type &,int) \endcode
       The second pattern is the time when calling the output.
       </li>
       <li> <b>CONSTRUCT_SIGNAL_OUT(signal_name,type)</b>
-      This macro is used in the constructor of the entity class handling this signal.
-      It creates the binding to the method described previously, and set the signal name to:
-      \code
-      EntityClassName(entity_name)::output(type)::signal_name
+      This macro is used in the constructor of the entity class handling this
+signal. It creates the binding to the method described previously, and set the
+signal name to: \code EntityClassName(entity_name)::output(type)::signal_name
       \endcode
       where entity_name is the name of the entity currently instanciated.
       </li>
 
       <li> <b>DEFINE_SIGNAL_OUT_FUNCTION(signal_name, type)</b>:
-      This macro is used when implementing the method specific to the output signal.
-      It is used in the main body of the entity class to declare the header of the method
-      with the following pattern:
-      \code
-      type EntityClassName::signal_nameSOUT_function(type &, int iter)
-      \endcode
+      This macro is used when implementing the method specific to the output
+signal. It is used in the main body of the entity class to declare the header of
+the method with the following pattern: \code type
+EntityClassName::signal_nameSOUT_function(type &, int iter) \endcode
       </li>
 
     </ul>
@@ -113,8 +107,8 @@ The header <b>entity-helper.h</b> is defining a type called EntityClassName
   </li> Inner signals
     <ul>
       <li> <b> DECLARE_SIGNAL_INNER(signal_name,type)</b>
-      Inner signal are signal that depend on a state of the entity and not on input signals.
-      This macro declares an inner signal with the following pattern:
+      Inner signal are signal that depend on a state of the entity and not on
+input signals. This macro declares an inner signal with the following pattern:
       \code
       m_signal_nameSINNER
       \endcode
@@ -124,11 +118,13 @@ The header <b>entity-helper.h</b> is defining a type called EntityClassName
       \endcode
       </li>
       <li> <b>DEFINE_SIGNAL_INNER_FUNCTION(signal_name,type)</b>
-      This macro is used to implement the method related to signal_name. More precisely
-      it provides the header of the member function(i.e. method) declaration.
+      This macro is used to implement the method related to signal_name. More
+precisely it provides the header of the member function(i.e. method)
+declaration.
       </li>
       <li><b>DECLARE_SIGNAL_INNER_FUNCTION(signal_name,type)</b>
-      This macros declares the member function used to handle the access to this signal.
+      This macros declares the member function used to handle the access to this
+signal.
       </li>
     </ul>
 </ul>

doc/additionalDoc/factory.h

@@ -2,6 +2,6 @@
 \page subp_factory Factory
 \section sec_factory Factory
 
-The class \ref dynamicgraph::FactoryStorage is a singleton which register the entity classes and which is allowing the
-instancation of such classes.
+The class \ref dynamicgraph::FactoryStorage is a singleton which register the
+entity classes and which is allowing the instancation of such classes.
 */

doc/additionalDoc/graph.h

@@ -6,14 +6,16 @@ In this package, the graph considered are directed graphs.
 
 In dynamic-graph a graph is build with:
 - computational nodes which are entities \subpage subpage_entities.
-- directed edges which are created by connecting input and output signals \subpage subp_signals.
-- managing the nodes is done through a factory \subpage subp_factory providing classes and a way to create instances
-from this list of classes.
+- directed edges which are created by connecting input and output signals
+\subpage subp_signals.
+- managing the nodes is done through a factory \subpage subp_factory providing
+classes and a way to create instances from this list of classes.
 - the instances of node are handled through a pool \subpage subp_pool
 
 We strongly recommend to use a scripting language such as Python to
 manage the graph.
-See <c>dynamic-graph-python</c> for more information on binding dynamic-graph with Python.
+See <c>dynamic-graph-python</c> for more information on binding dynamic-graph
+with Python.
 
 It is possible to display the graph of entities \subpage writegraphdoc
 

doc/additionalDoc/installation.h

@@ -13,7 +13,8 @@ dynamic-graph depends on:
 \section sec_inst_get_src Getting the source
 
 The sources are available through github at the following URL:
-<a href="https://github.com/stack-of-tasks/dynamic-graph">https://github.com/stack-of-tasks/dynamic-graph</a>
+<a
+href="https://github.com/stack-of-tasks/dynamic-graph">https://github.com/stack-of-tasks/dynamic-graph</a>
 
 To clone:
 \code

doc/additionalDoc/introduction.h

@@ -3,63 +3,65 @@
 \section intro_dynamicGraph Introduction
 
 The dynamic-graph package is used to connect computation nodes, "entities"
-together using a graph system, akin to what Simulink does. Entities are connected
-through input and output signals.
-With the building blocks this package provides, you can easily create a full computation graph
-for a given problem. It is the basis for the stack of tasks operation.
+together using a graph system, akin to what Simulink does. Entities are
+connected through input and output signals. With the building blocks this
+package provides, you can easily create a full computation graph for a given
+problem. It is the basis for the stack of tasks operation.
 
 
 \subsection controlgraph Exemple: Real-time control
 
-<p>To give a more concrete example, the real-time control used by the Gepetto group for the humanoid robot HRP-2
-is detailled.</p>
-<p>
-Real-time control system are usually driven by a cyclic computational node which
-needs to send a control reference value to each motors of a robot. To compute this
-control reference values, sensor values need to be provided.
-In the Stack-Of-Tasks special entities called Device are used to
-provide an abstract interface to the hardware.</p>
-A scheme of the real-time control graph used for the humanoid robot HRP-2 is depicted in the following figure:
+<p>To give a more concrete example, the real-time control used by the Gepetto
+group for the humanoid robot HRP-2 is detailled.</p> <p> Real-time control
+system are usually driven by a cyclic computational node which needs to send a
+control reference value to each motors of a robot. To compute this control
+reference values, sensor values need to be provided. In the Stack-Of-Tasks
+special entities called Device are used to provide an abstract interface to the
+hardware.</p> A scheme of the real-time control graph used for the humanoid
+robot HRP-2 is depicted in the following figure:
 
 \image html Concept-Software-Fig.png
 
-You can find an example of a real example of control graph at \ref writegraphdoc.
+You can find an example of a real example of control graph at \ref
+writegraphdoc.
 
-<p>The device therefore has a specific input which should contain the control vector.
-This control vector is the result of a computation solving a control problem.
-The entity in charge of solving this control problem is called "Solver" in the previous
-figure.
-In the SoT framework it is often cast as an optimization problem.
-This optimization problem is build using a control "Task" (not to be confused with the
-general word task). A control "Task" regulates the difference with a "Feature" computed
-on the current robot state and a "Desired Feature". For instance when walking, the regulated
-feature is the robot's Center-Of-Mass (CoM) position. The "Feature" is computed using a
-library using the robot model and the sensor value. The entity making this computation is "Dyn".
-A walking pattern generator using foot-steps position given in advance generates the desired
-value for the CoM.
-Note that the "Dyn" entity uses the sensor provided by the entity "Robot". </p>
+<p>The device therefore has a specific input which should contain the control
+vector. This control vector is the result of a computation solving a control
+problem. The entity in charge of solving this control problem is called "Solver"
+in the previous figure. In the SoT framework it is often cast as an optimization
+problem. This optimization problem is build using a control "Task" (not to be
+confused with the general word task). A control "Task" regulates the difference
+with a "Feature" computed on the current robot state and a "Desired Feature".
+For instance when walking, the regulated feature is the robot's Center-Of-Mass
+(CoM) position. The "Feature" is computed using a library using the robot model
+and the sensor value. The entity making this computation is "Dyn". A walking
+pattern generator using foot-steps position given in advance generates the
+desired value for the CoM. Note that the "Dyn" entity uses the sensor provided
+by the entity "Robot". </p>
 
 <p>
-From a pure computer science viewpoint we wish to avoid recomputing data such as articular Jacobians
-when this is unnecessary. Therefore the data generated by an entity through signals may have two types of
-dependencies: one dependency related to time and dependencies on other signals. Internally an entity
-does not recompute the data if no new information is available, it is simply providing the same information
-computed before. Please note that this package provides only the computational framework to realize
-the data dependency and the entities. Solvers, libraries to compute mechanical quantities are provided
-in different packages.
+From a pure computer science viewpoint we wish to avoid recomputing data such as
+articular Jacobians when this is unnecessary. Therefore the data generated by an
+entity through signals may have two types of dependencies: one dependency
+related to time and dependencies on other signals. Internally an entity does not
+recompute the data if no new information is available, it is simply providing
+the same information computed before. Please note that this package provides
+only the computational framework to realize the data dependency and the
+entities. Solvers, libraries to compute mechanical quantities are provided in
+different packages.
 </p>
 
 <p>
-Finally in order to dynamically create a graph, it is possible \b on-line to load classes of entities  and
-create instances of entities.</p>
+Finally in order to dynamically create a graph, it is possible \b on-line to
+load classes of entities  and create instances of entities.</p>
 
 \subsection Functionnalities
 
 \li Support for extensions and modules using dynamic link libraries
 \li Template-based signal definition, independent
 \li Type-safe connection of input and output signals
-\li On-demand signal computation as well as a caching system for signal values allow fast
-computation of signal values, which is a critical point for real-time systems\n
-See \ref scriptingabout
+\li On-demand signal computation as well as a caching system for signal values
+allow fast computation of signal values, which is a critical point for real-time
+systems\n See \ref scriptingabout
 
 */

doc/additionalDoc/package.h

@@ -22,16 +22,19 @@ The software graph structure is detailled in \subpage p_graph
 
 For debugging your entities detailed instructions are given in \subpage debug
 
-For citing the software in your research work please refer to \subpage subp_references
+For citing the software in your research work please refer to \subpage
+subp_references
 
-\namespace dynamicgraph This is the namespace where every object and class of this library is located.
+\namespace dynamicgraph This is the namespace where every object and class of
+this library is located.
 
 \defgroup debug Debugging
 
 \defgroup dgraph Core classes and objects
 @{
 
-Classes, entities and binaries that make up the core of the dynamic-graph library are listed here.
+Classes, entities and binaries that make up the core of the dynamic-graph
+library are listed here.
 @}
 
 \defgroup signals Signals
@@ -40,11 +43,13 @@ This part provides the mechanism to transfer information
 from one entity to another. There are three main types of signals,
 all deriving from the common class dynamicgraph::SignalBase :
 \li dynamicgraph::Signal : a "normal" signal, passing data around \b by \b value
-\li dynamicgraph::SignalPtr : a signal used for efficient passing of large data, by reference (or rather, C pointers)*
-\li dynamicgraph::SignalTimeDependent : a signal that enforces a time dependency between other signals,
-making sure its inputs are up to date on access, using a incrementing time tick as reference.
+\li dynamicgraph::SignalPtr : a signal used for efficient passing of large data,
+by reference (or rather, C pointers)* \li dynamicgraph::SignalTimeDependent : a
+signal that enforces a time dependency between other signals, making sure its
+inputs are up to date on access, using a incrementing time tick as reference.
 
-\n* Note: this may cause a problem if this package is used in a multithreaded program.
+\n* Note: this may cause a problem if this package is used in a multithreaded
+program.
 
 Signals can be grouped together using dynamicgraph::SignalArray.
 
@@ -54,8 +59,8 @@ For more information, please see the individual signal pages.
 
 \b Samples
 
-\li The following code ensures the jacobian output signal uses up-to-date values for its
-computations, when accessed.
+\li The following code ensures the jacobian output signal uses up-to-date values
+for its computations, when accessed.
 
 \code
   // This signal returns the Jacobian of the current value

doc/additionalDoc/pool.h

 /**
 \page subp_pool Pool
 \section pool Pool
-The class \ref dynamicgraph::PoolStorage keeps track of the entities instanciated with the factory.
-The entities are the graph nodes. Signals are constructed during the class instanciation, they do not live
-independently from the entities. Signals are the directed edges of the graph. The pool can write a file representing
-the graph of entities.
+The class \ref dynamicgraph::PoolStorage keeps track of the entities
+instanciated with the factory. The entities are the graph nodes. Signals are
+constructed during the class instanciation, they do not live independently from
+the entities. Signals are the directed edges of the graph. The pool can write a
+file representing the graph of entities.
 */

doc/additionalDoc/references.h

@@ -7,8 +7,8 @@ Please when referencing the Stack-Of-Tasks use the following reference:
 \anchor Mansard2009
 
 <b> <a href="https://hal-lirmm.ccsd.cnrs.fr/lirmm-00796736/document">
-"A versatile Generalized Inverted Kinematics implementation for collaborative working humanoid robots: The Stack Of
-Tasks"</a>
+"A versatile Generalized Inverted Kinematics implementation for collaborative
+working humanoid robots: The Stack Of Tasks"</a>
 </b>,
 <em>N. Mansard, O. Stasse, P. Evrard, A. Kheddar,</em>
 Int. Conf. on Autonomous Robots, ICAR, 2009

doc/additionalDoc/signal.h

@@ -2,11 +2,10 @@
 \page subp_signals Signals
 \section sec_sigintro Signals
 
-Entities can output different types of signals. To guarante real-time perforamces, signals are implemented
-using C++ and mecanism which have a low time foot-print.
-All signals are templated by a Time
-tick type parameter (which is used in the caching of signals) - usually \c int. Signals
-are also templated after the type of data they accept or provide. For example:
-(example)
-For a more detailed programmer-oriented description of signals, please see \ref signals
+Entities can output different types of signals. To guarante real-time
+perforamces, signals are implemented using C++ and mecanism which have a low
+time foot-print. All signals are templated by a Time tick type parameter (which
+is used in the caching of signals) - usually \c int. Signals are also templated
+after the type of data they accept or provide. For example: (example) For a more
+detailed programmer-oriented description of signals, please see \ref signals
 */

doc/additionalDoc/tracer-real-timedoc.h

@@ -2,9 +2,9 @@
 \page tracerrealtimedoc TracerRealTime
 
 \section tracerrealtimedoc_description Description
-The \b TracerRealTime entity monitors a set of signals with real-time constraints; its
-function is very similar to the Tracer, except that all traces are recorded to a
-memory buffer, which can be emptied at any time.
+The \b TracerRealTime entity monitors a set of signals with real-time
+constraints; its function is very similar to the Tracer, except that all traces
+are recorded to a memory buffer, which can be emptied at any time.
 
 \section tracerrealtimedoc_commands Commands
 The \b commands that this entity exposes are:

doc/additionalDoc/tracerdoc.h

 /**
 \page tracerdoc Tracer
 \section tracerdoc_description Description
-The \b Tracer entity monitors a set of signals. With an input change on the entity's [trigger] signal,
-the tracked signal values are recorded and traced to a file. The behavior of the trace-to-file
-function can be changed, from printing to a file immediately after recording, to printing out
-only when asked explicitly.
+The \b Tracer entity monitors a set of signals. With an input change on the
+entity's [trigger] signal, the tracked signal values are recorded and traced to
+a file. The behavior of the trace-to-file function can be changed, from printing
+to a file immediately after recording, to printing out only when asked
+explicitly.
 
 \section tracerdoc_commands Commands
 The \b commands that this entity exposes are:

doc/additionalDoc/writeGraph.h

@@ -21,6 +21,7 @@ It provides the following output:
 
 \section fromdottojs Viewing in a browser
 To view the dot file you can simply use the view_sot_dg.html file.
-Click on the "Choose File" to specify the filem and click on "Rendering" to display the graph.
+Click on the "Choose File" to specify the filem and click on "Rendering" to
+display the graph.
 
 */

include/dynamic-graph/all-commands.h

@@ -12,7 +12,7 @@
 #include <dynamic-graph/command-direct-getter.h>
 #include <dynamic-graph/command-direct-setter.h>
 #include <dynamic-graph/command-getter.h>
-#include <dynamic-graph/command.h>
 #include <dynamic-graph/command-setter.h>
+#include <dynamic-graph/command.h>
 
-#endif  //! DYNAMIC_GRAPH_ALL_COMMANDS_H
+#endif //! DYNAMIC_GRAPH_ALL_COMMANDS_H

include/dynamic-graph/all-signals.h

@@ -8,8 +8,8 @@
 
 // Utility header files including all signal headers
 
-#include <dynamic-graph/signal.h>
 #include <dynamic-graph/signal-ptr.h>
 #include <dynamic-graph/signal-time-dependent.h>
+#include <dynamic-graph/signal.h>
 
-#endif  //! DYNAMIC_GRAPH_ALL_SIGNALS_H
+#endif //! DYNAMIC_GRAPH_ALL_SIGNALS_H

include/dynamic-graph/command-direct-getter.h

@@ -19,45 +19,38 @@
 #include <boost/assign/list_of.hpp>
 
 /* --- GETTER --------------------------------------------------------- */
-namespace dynamicgraph
-{
-  namespace command
-  {
-
-    template <class E, typename T>
-    class DirectGetter : public Command
-    {
-    public: