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?