Re: [boost] [serialization] boost/serialization/path.hpp

Subject: Re: [boost] [serialization] boost/serialization/path.hpp
From: gast128 (gast128_at_[hidden])
Date: 2011-02-21 07:06:11

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?