[boost] Re: [fileststem]1.32: with serilization: visibility of m_path

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-11-08 12:48:39

Note that making one's code "serialization friendly" does not require
inclusion of
a header from the serialization library.

In most cases it should be sufficient to include
namespace boost { namespace serialization { class access; } }
and

friend class boost::serialization::access;

in each class definition.

I don't think that's a huge burden.

Every week I get an email - how about adding serialization to this or that
class.  It would be better
if sometime in the future we could agree on some sort of policy or practice
to include this
whereever appropriate.

So far it hasn't been a big thing - but I'm thinking that when 1.32 gets
released this may start to
become a bigger issue.

Robert Ramey

"Jeff Garland" <jeff_at_[hidden]> wrote in message
news:20041108171108.M66733_at_crystalclearsoftware.com...
> On Mon, 08 Nov 2004 11:07:16 -0500, Beman Dawes wrote
> > * Adding a dependency to the serialization library isn't a good idea
> > either. No matter how nice boost.serialization is, some
> > boost.filesystem users will not wish to use it, and will not want
> > the dependency.
>
> Since the needed code for serialization is basically a template function
the
> dependency can be limited to those using serialization by having a new
header
> for serialization code.  So in date-time we have something like:
>
> #include <boost/date_time/posix_time/time_serialize.hpp>
>
> Filesystem could do something similar.
>
> > Class path already has a member, path::string(), which in the
> > current implementation returns a reference to m_path, and in any
> > implementation must return the equivalent of a const reference to
> > m_path. Going the other way, the append function can be used to
> > import a serialized string. I'm not familiar with how
> > boost.serialization works, but wouldn't you be better off to use
> > those already public functions for serialization?
> >
> > If not, I'm willing to make m_path protected, but would like to
> > explore other approaches to the serialization problem first.
>
> I think you could easily write your serialization functions to just use
the
> string() interface.
>
> Jeff
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>