On Thu, Mar 05, 2009 at 09:49:58AM +0100, Ola Skavhaug wrote: > On Thu, Mar 5, 2009 at 9:46 AM, Anders Logg <[email protected]> wrote: > > On Thu, Mar 05, 2009 at 09:36:05AM +0100, Ola Skavhaug wrote: > >> As some might have seen from the buildbot's failures last night, we're > >> currently implementing a nested stack based xml parser that enables > >> the reuse of the different parsers (we call them XMLHandlers) when > >> reading and writing data to xml files. We want to use the handlers for > >> both input and output, and we run into problems at construction time. > >> For instance, when writing a std::vector<uint, int> x to file, we get > >> a const reference, and need to cast away the constness in order to > >> construct the XMLArray object: > >> > >> > >> void NewXMLFile::operator<<(const std::vector<int>& x) > >> { > >> XMLArray xml_array(const_cast<std::vector<int>&>(x), *this); > >> xml_array.write(filename); > >> } > >> > >> Does anyone object to this const_cast? > > > > Is this because the handlers are used both for reading and writing? > > > > One option would be to split it into two files, one for reading and > > one for writing but that is inconvenient. How about instead having two > > objects as arguments to the constructor: > > > > XMLFoo(Foo* input_foo, const Foo* output_foo, NewXMLFile& parser); > > > > Then we need to dolfin_assert() the pointers and use the correct one > > for input and output. > > Sure, this could be done, but we'll swamp the object with pointers. > For example, the XMLMap already has 6 non-const pointers. Your > suggestion will double this :) > > Ola
ok, how about making the input object(s) non-const and only use them
for input.
For output, we instead have static members that take const objects:
class XMLMesh
{
public:
...
static write(const Mesh& mesh, stream_or_whatever, uint
indentation_level=0);
};
Then XMLFile just calls XMLMesh::write(), which may in turn call
XMLMeshData::write() etc.
--
Anders
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
