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
dependency can be limited to those using serialization by having a new
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
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@crystalclearsoftware.com> wrote in message news:20041108171108.M66733@crystalclearsoftware.com... the header the
string() interface.
Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost