|typedef bool(*||ProcFunc )(Process &, const std::string &, Finder &)|
|Process function type. More...|
|Attempts to read the header of |
|void||registerProcessType (const std::string &objType, const std::string &dataType, ProcFunc procFunc)|
|Registers the process to call on a given (object type, data type) couple (just fills the map) More...|
|bool||execute (const std::string &filename)|
|Executes the process on the object / data type found in the given file. More...|
|bool||execute (Finder &f, const std::string &filename)|
|Same as above but the header has already been read (or hand-made to fake it!) More...|
|const std::map< std::string, |
ProcFunc > > &
|processTypes () const|
|Query registered process types. More...|
|void||setReadOptions (carto::Object options)|
|Set reading options. More...|
|std::map< std::string, |
ProcFunc > >
Link mechanism between the Finder and a process operating on arbitrary data types.
Process finally solves the data-type problem for every AIMS commandline (I hope...). It allows to hide both the file format of processed data (using Finder) and the data type dependency. Process allows to call a process operation function depending on the correct data type given by its file info (using a functions map).
No type switching need to be hard-coded anymore. Process uses a plugin mechanism for new data types and the types list can be dynamically extended when needed.
Usage: Subclass Process to your own class with either an external
or a static member function:
Instantiate such a process class, and register every needed type with the registerProcessType() function (you can do it in your process constructor). Then call the execute() function with your file name as an argument. The process function registered for the correct data type will be called, if this type can be guessed by the Finder, or return false if it fails.
In fact if your process doesn't need other information (no data in your Process subclass), you don't even really need to subclass it: manually registering processing functions should be enough.
An example of it: the AimsFileInfo command
For quick use, another small example:
int) and on volumes of complex, and use specific operations for the former (ie ordering, comparisons operations or casting to
double) which would not work on the latter.
Process function type.
These functions are stored in a type-to-function map and called by the execute() function. They are called with the file name of the object and the corresponding Finder object, the Finder::check() has already been successfully called by execute(), so the file header is available in the Finder. Each function must be specialized for a given object and data type (possibly using template functions). Unfortunately these functions pointers can not be pointer to member functions as we will need access to derived classes members (not allowed in C++ spec), so we also provide a reference to
this Process object to the process function (callback-style)
Attempts to read the header of
filename and, if successful, calls the
operator() of the process .
|bool aims::Process::execute||(||const std::string &||filename||)|
Executes the process on the object / data type found in the given file.
Uses Finder to figure out which data should be used. This will either call the registered ProcFunc or return
false if no process function has been registered on that type
|bool aims::Process::execute||(||Finder &||f,|
|const std::string &||filename|
Same as above but the header has already been read (or hand-made to fake it!)
|void aims::Process::registerProcessType||(||const std::string &||objType,|
|const std::string &||dataType,|
Registers the process to call on a given (object type, data type) couple (just fills the map)
Referenced by aims::AimsGraphReader::read().
Set reading options.
Reading options are used for two things:
preferred_data_typewill force using this data type if it is supported amongst the Finder::possibleDataTypes() list, to overwrite the default one.