RVL::DataContainer Class Reference

DataContainer is the principal RVL abstraction for types encapsulating data structures. More...

#include <data.hh>

Inheritance diagram for RVL::DataContainer:

RVL::Writeable RVL::ProductDataContainer RVL::StdProductDataContainer List of all members.

Public Member Functions

 DataContainer ()
 DataContainer (const DataContainer &)
virtual ~DataContainer ()
virtual void eval (FunctionObject &f, vector< DataContainer const * > &x)=0
 Evaluate a function object.Concrete subtypes must supply this definition in order to properly exploit the data structures which they encapsulate.
virtual void eval (FunctionObjectConstEval &f, vector< DataContainer const * > &x) const =0
 Const version of evaluation.

Detailed Description

DataContainer is the principal RVL abstraction for types encapsulating data structures.

This abstract type is intended to encompass an arbitrary number of levels of indirection (cartesian product structures, for example, or trees, or...) hence provides no actual access to data. All interaction with data takes place through evaluation of FunctionObjects.

In GoF terms, the FO and DC hierarchies together exemplify the Visitor pattern, in its Acyclic variant defined by Martin. The DCs are the Visited types (i.e. the Elements, in terms of the GoF chapter).

We have chosen to locate control of evaluation in the DataContainer class rather than in the FunctionObject class. This decision is standard in the Visitor pattern, i.e. that the visited type controls access, and allows FunctionObjects to be reused across wide categories of DataContainers, without needing to be aware of data structure details. If we were to locate control in the FunctionObject type, then each FO would need to be coded to deal correctly with every type of DC. Many FOs are simple scalar operations, like linear combination, which are evaluated in the same way on every DataContainer at the level of data, but which need not be aware of the overall structure if DataContainers control execution.

Ultimately some DataContainer subtype must actually provide access to data, else nothing happens. An example of such a construction is the LocalDataContainer class template in LocalRVL.

Definition at line 169 of file data.hh.


Constructor & Destructor Documentation

RVL::DataContainer::DataContainer (  ) 

Definition at line 172 of file data.hh.

RVL::DataContainer::DataContainer ( const DataContainer  ) 

Definition at line 173 of file data.hh.

virtual RVL::DataContainer::~DataContainer (  )  [virtual]

Definition at line 174 of file data.hh.


Member Function Documentation

virtual void RVL::DataContainer::eval ( FunctionObject f,
vector< DataContainer const * > &  x 
) [pure virtual]

Evaluate a function object.Concrete subtypes must supply this definition in order to properly exploit the data structures which they encapsulate.

For example the ProductDataContainer structure defined in productdata.H implements evaluation via a loop over factors.

Referenced by RVL::ProductDataContainer::eval(), RVL::StdSpace< Scalar, DataType >::inner(), RVL::StdSpace< Scalar, DataType >::linComb(), and RVL::StdSpace< Scalar, DataType >::zero().

virtual void RVL::DataContainer::eval ( FunctionObjectConstEval f,
vector< DataContainer const * > &  x 
) const [pure virtual]

Const version of evaluation.


The documentation for this class was generated from the following file:
Generated on 5 Jan 2017 for RVL by  doxygen 1.4.7