Re: [lmi] Boost.Filesystem v3

[Greg Chicares]

On 2011-06-20 21:51Z, Vadim Zeitlin wrote:
> 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

We use their regex library only for one auxiliary program that's independent
of lmi. Aside from that, all the boost libraries we use are implemented in
headers only, except for boost::filesystem. That library has only four '.cpp'
files to compile, totaling about 60K. Compiling them produces 620K of object
files out of a total of 73M with gcc-3.4.5: about one percent of the total.

Using a prebuilt boost binary saves us that one percent when we rebuild from
scratch, and zero percent when we re-make. But it makes us subject to boost's
whims: whenever they decide to make an incompatible change, we're forced to
change lmi. That's what I want to avoid.

Last time we looked into a later boost version, IIRC, the filesystem library
had acquired dependencies on other libraries' '.cpp' files. I guess they're
making boost more monolithic over time. That's yet another reason to wait
for TR2...

> - 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.

This proposal had basic_path:
  http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2005/n1889.html
The more recent proposal removes that (but leaves seven open "TODO" items, so
it's likely to change again). If we had followed each revision of the proposal,
we'd have needed to change lmi more than once. I'm glad we avoided that.

> - 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.

We're using v1, which doesn't have basic_path. I understand the v1 API, so
I can easily enough write new code that uses 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.

They don't necessarily "maintain" code in the sense of fixing defects while
preserving binary compatibility, the way wx does. I'd say their code "evolves",
which is how standards are written--but not how production libraries are best
maintained. Therefore:

http://www.boost.org/users/faq.html
| How can the Boost libraries be used successfully for important projects?
| Many of the Boost libraries are actively maintained and improved, so
| backward compatibility with prior version isn't always possible. Deal with
| this by freezing the version of the Boost libraries used by your project.
| Only upgrade at points in your project's life cycle where a bit of change
| will not cause problems. Individual bug fixes can always be obtained from
| the boost repository.

I don't see any real problem with remaining frozen at 1.33.1 . We've never
needed to obtain any fixes from later boost versions. We have many higher
priorities, and little enough time for them.