[Dune] Fwd: Re: Communicating IdSet elements

[Martin Nolte]

Hi Jö,

don't get me wrong: I don't want to reinvent the wheel. I just think that two
wheelmakers are better than one. What I mean to say is that I would prefer a
DUNE style solution: We provide an abstract interface and the actual choice of
the serialization library is up to the user.

And, yes, if possible I would like to keep the core modules clean of any Boost
stuff, since I am under the impression that Boost frequently breaks
compatibility. For the people loving Boost you could create a separate
dune-boost module providing all those "nice" extensions.

Best,

Martin

On 07/24/2011 10:34 PM, Jö Fahlke wrote:
> Am Sun, 24. Jul 2011, 21:00:59 +0200 schrieb Martin Nolte:
>> while we might learn from Boost how to do seriaization properly, I don't think a
>> dependency on boost a good idea. Furthermore, glancing over the
>> Boost::Serialization documentation, they are intended to be non-intrusive, i.e.,
>> given "good" operations for conversion to and from binary, you could use boost
>> on top of dune-grid. I would very much prefer such an approach over dependencies
>> on boost.
> 
> Looking at it myself now.  As far as I can see, providing save/load facilities
> for simple cases should be possible without actually including
> Boost.Serialization.  We may need to define an empty namespace
> boost::serialization somewhere to allow things like
> 
>   friend class boost::serialization::access;
> 
> But that shouldn't be a big problem.  More complicated things are derived
> classes where the base classes have to be serialized as well, the
> documentation says
> 
> | Do *NOT* directly call the base class serialize functions.  Doing so might
> | seem to work but will bypass the code that tracks instances written to
> | storage to eliminate redundancies.  It will also bypass the writing of class
> | version information into the archive.  For this reason, it is advisable to
> | always make member serialize functions private.  The declaration friend
> | boost::serialization::access will grant to the serialization library access
> | to private member variables and functions.
> 
> Worst case means we have to do #if HAVE_BOOST_SERIALIZATION.  Given there are
> a lot ob things you'd want to serialize potentially, that might mean a lot of
> prepreocessor-ifs.
> 
> So, I suppose providing the hooks necessary for serialization on Dune classes
> would be feasible without actually requiring Boost.Serialization to be
> present.  All the hooks are templates, so there isn't even an implication for
> the libraries (though classes with a VMT might need a closer look here).  Only
> users who actually use serialization (directly or indirectly) are required to
> compile with Boost.Serialization.
> 
> I'm not really convinced that we should reimplement the actual serialization
> facilities, however.  This isn't really our job and may well be more trouble
> than it's worth.
> 
> Bye,
> Jö.
> 

-- 
Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5630
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany