On Sep 23, 2008, at 7:32 AM, Johan Råde wrote:

Let's keep it simple, and use the default traits.

Robert, can I commit the following to the trunk?

Why don't you put that into the file system library instead of the serialization library? Matthias

Sure - just don't put it into the serialization library directories. a couple of problems. a)There is no test. b)No documentation regarding string traits requirments and whatever well that's enough. Maybe you want to put this into the file system directory. Or maybe in the vault to see if there is a wide interest. Robert Ramey Johan Råde wrote:

Let's keep it simple, and use the default traits.

Robert, can I commit the following to the trunk?

--Johan Råde

-----------------------------------------------------------------------------------

#ifndef BOOST_SERIALIZATION_PATH_HPP #define BOOST_SERIALIZATION_PATH_HPP

// MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) #pragma once #endif

#include <boost/config.hpp> #include <boost/filesystem/path.hpp> #include <boost/serialization/level.hpp>

namespace boost { namespace serialization {

template<class Archive, class String, class Traits> void serialize(Archive& ar, boost::filesystem::basic_path<String, Traits>& p, const unsigned int version) { String s; if(Archive::is_saving::value) s = p.string(); ar & boost::serialization::make_nvp("string", s); if(Archive::is_loading::value) p = s; }

}}

#endif

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Robert Ramey <ramey <at> rrsd.com> writes:

gast128 wrote:

...

I did an attempt to get this in Boost.Serialization, but author doesn't like it. See https://svn.boost.org/trac/boost/ticket/5192.

I do not agree with his arguments though (filesystem is a quite library stable, so there is not a big chance of high maintenance work; the dependency is also little, it can be in one header file;

what's the problem with putting that file into boost/filesystem ... like the other types do?

If u put it the other way around, one gets Boost.Serialization included if using Boost.Filesystem (technically this may depend on the actual headers include, but from a conceptual point of view). Imho Boost.Filesystem is a basic concept, representing a path (instead of using raw std::string's), so I can imagine in time that e.g. iostream and Boost.Serialization uses Boost.Filesystem when a path is used in its interface. Same argument goes for Boost.DateTime (as being a representation of a c++ date time).

...

there is already a dependency from Serialization on external libraries such as on shared_ptr).

This is an exception case - it was just too hard for anyone else to do.

Agree, but it wasn't put in the smart pointer library for good reason?

...

I suppose this idea is dead then?

Only the idea of putting into the serialization library is dead. You're free to put it anywhere else.

Fwiw if u need a concept which uses library A and library B, there is always a question where to put it (i.e. in library A or B). I would model it like layers, where higher concepts are dependent on more basic concepts. If library A and B are equal in that respect, one could go for a new layer. In practice that could introduce a Boost.Rest (or Misc) library?

Le 21/02/2011 16:55, Matthias Troyer a écrit :

...

Agree, but it wasn't put in the smart pointer library for good reason?

Yes, archives need to explicitly support smart pointers, which is not the case for filesystem.

And it would be nice if they could be modified to handle std::shared_ptr as well as boost::shared_ptr... -- Loïc