Re: [lmi] Boost.Filesystem v3

[Vadim Zeitlin]

On Mon, 20 Jun 2011 21:11:27 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2011-06-20 18:23Z, Vadim Zeitlin wrote:
GC> [...boost is revamping their filesystem library...]
GC> >  Of course, I can just ignore this problem for now and use the still
GC> > provided v2 and ignore the deprecation warnings. OTOH it looks like LMI
GC> > would need to start using v3 sooner or later
GC> 
GC> What bad thing will happen if we just stay with boost-1.31.1?

 Nothing really bad but a few good things will not happen:

- Using the system library under Linux systems will become impossible as
  they typically don't provide very old versions of the libraries. E.g.
  Debian only has 1.34 in Lenny (== oldstable) and the current stable
  version (Squeeze) only has 1.42 while testing has 1.46 in which v3
  version of the file system library is the default. Debian being one
  of the most conservative Linux distributions, I'd expect the others to be
  even worse from this point of view. This is not catastrophic as we can
  continue building it from sources ourselves but IMHO it's an unnecessary
  complication when we can just use the system library that is available on
  all Unix systems.

- Boost.Filesystem v3 is part of TR2 proposal, see
  http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2011/n3239.html and
  so might become part of the C++ standard in some (admittedly, not very
  close) future so using its API would make it easier to use
  std::filesystem::path class in the future.

- Boost.Filesystem v3 API is markedly better than v2 (I feel especially
  vindicated because they now use the same sane approach as wxFileName uses
  instead of the previously inexplicable design using basic_path<> which I
  hated with a passion... Now if only somebody wrote a next version of
  Boost.ProgramOptions library...). So I feel it would be easier to use if
  any more code using it needs to be written. Of course, this doesn't apply
  if you never intend to write anything using it.

 More generally I think it's a bad idea to stick to a fixed old version of
the library which is certain to not be maintained any longer. Especially
when the new version is promising to become standard and is markedly
better. But this is more of a general feeling than a precise argument. In
practice, only the first point risks being a problem for us in the
foreseeable future.

 Regards,
VZ