GitLab

ENH: Remove getHDF5Type from XdmfArray and move into XdmfHDF5Writer so all hdf5 interaction is isolated
in XdmfHDF5Writer.  Friend the XdmfHDF5Writer from XdmfArray so that it can access the variant to perform
typesafe operations on the data stored.  Variable macro generation didn't work so reverted the modified code.
We may just have to write ugly static New() methods when required.

ENH: Split heavy data writing from XdmfWriter into XdmfHDF5Writer.  This paves the way for the possiblity of having multiple
heavy data and light data writers.  Modify New() macro to accept parameters.

to write out the Xdmf graph.  Modify some random include statements for style.

ENH: Create a generic XdmfVisitor class and move writing operations to XdmfWriter.  Incorporate Loki library to perform asymmetric visitor operation (allows customizable behavior for eventual Xdmf / NetDMF library split).  Modify Loki
Visitor to work happily with boost::shared_ptr and modify swig wrapping to properly handle boost::shared_ptr inheritance.

STYLE: Split XdmfArray.tpp from XdmfArray.hpp --- this will hold template implementations for XdmfArray instead of stuffing them all in XdmfArray.hpp (merely a style difference).  Do some minor formatting on some other files.

unnecessarily duplicated functionality.

ENH:  Replace old way of creating static instances of XdmfTopologyType, XdmfGeometryType, and storing them by reference in their respective topologies.  These now work by providing a specific constructor method that returns specific instances of the objects populated with correct values.  This was changed because there are some type options in Xdmf where static instances don't make sense (e.g. XdmfTopologyType Polygon can have many different values for nodesPerElement) but we still need to restrict construction of these types with specific values.  Each parent item merely keeps a copy of a topology type.  I considered doing this with smart pointers, but I believe it to be unnecessarily complicated, especially when direct comparison of topology types is needed.  I am considering separating these types into separate classes.

Added XdmfAttribute implementation and began populating XdmfVisitor to write out XML.

ENH: Add XdmfGeometryType to XdmfGeometry in a similar implementation as XdmfTopologyType.  Add tests for XdmfGeometry.  Add XdmfItem, an abstract class that is able to be traversed by an XdmfVisitor to write out its information to XML and HDF5 or other heavy data formats.  Modify XdmfGeometry, XdmfGrid, XdmfTopology, and XdmfAttribute to inherit from XdmfItem.

ENH: Added XdmfTopologyType to XdmfTopology to handle element types and associated const data like nodesPerElement and name.  This resembles "Replace subclass with fields" implementation in Refactoring and does a nice job encapsulating element type data in an enum like way avoiding unneccesary subclassing.