Re: [lmi] Cross-compiling lmi from Linux to MSW

[Greg Chicares]

On 2016-01-21 20:41, Vadim Zeitlin wrote:
> On Thu, 21 Jan 2016 01:52:31 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2016-01-14 01:35, Vadim Zeitlin wrote:
[...]
> GC> > Notice that the commands above do not use "-std=c++11" for compiling for
> GC> > the good reason that Boost 1.38 doesn't build with this option
[...]
> GC> Yet it does seem to compile natively in msw with '-std=c++11',
> GC> so isn't it really strange that the cross-compiler fails?
> 
>  Oops. I know what happened here: I used Boost 1.38 which is used in our
> branch of lmi as we had to upgrade to it to use boost::math::expm1() and
> log1p() 6+ years ago:

Yet we use expm1() and log1p() in production, without boost replacements.
I guess you must have done that for msvc, which can't handle the inline
asm in lmi's 'expm1.c'. Well...nobody on this continent compiles lmi with
msvc, and you probably don't care about the exact numerical results of
lmi's compound-interest calculations, so...why not just use
  exp(x) - 1
and
  log(1+x)
for msvc? E.g.:

double expm1(double x)
{
// ...some suitable comment about msvc...
#if !defined LMI_MSC
  if (fabs(x) < LOGE2L)
    {
      x *= LOG2EL;
      __asm__("f2xm1" : "=t" (x) : "0" (x));
      return x;
    }
  else
#endif // !defined LMI_MSC
    return exp(x) - 1.0;
}

and similarly for log1p().

> The patch using these functions which was submitted soon afterwards has
> never been applied to lmi mainline and so it stayed at Boost 1.33. And
> while Boost 1.38 is so old that it uses rvalue references with non-standard
> semantics they had in the very early stages of C++11 development, Boost
> 1.33 is so incredibly ancient that it doesn't use rvalue references at all
> and so, in virtue of its extreme age, can be compiled in C++11 mode when
> 1.38 can't.

That's really excellent news from my POV. Perhaps I can just add
'-std=c++11' to every compile command, and it'll all just work.

> GC> The only other not-all-headers boost library we use is 'regex',
> GC> and that seems to be provided by gcc now that it's a standard:
> GC>   i686-w64-mingw32/include/c++/regex
> 
>  Yes, 4.9 is the first g++ version to support std::regex (unfortunately,
> std::filesystem is only supported in 5.x).
> 
> GC> If we switch 'regex' to the system library, then 'filesystem' is our
> GC> only headache. If we sequester 'filesystem' in its 1.38 version, then
> GC> we can upgrade boost easily any time, right?
> 
>  I hoped we could avoid using Boost at all with C++ but it looks like it
> wouldn't be (easily) possible because of Boost.Any.

If that's the only obstacle, then it's easy to overcome. That's a header-
only library even in 1.38, and it looks very much like Henney's original
magazine article, which didn't depend in any way on boost IIRC.

> Just FYI, currently we
> use the following Boost headers:
> 
> ---------------------------------- >8 --------------------------------------
> % git grep boost/|sed -n 
> '/#include/address@hidden<\([a-z_/]*\.hpp\)address@hidden@p'|sort|uniq

[snip list]

Does standard C++ now provide all of them except 'any' and 'filesystem'?
If so, then we can freeze those two parts and purge the rest.

>  To summarize, we can continue using Boost 1.33 for now because it's über
> ancient enough to not have problems with C++11, so upgrading Boost is not
> as urgent as I thought
[...]
>  However I still think that it would be worth it to:
> 
> (a) Replace as much as possible of Boost classes with C++11 ones now that
>     we can do it (this includes scoped_ptr, shared_ptr, regex, ...).

Absolutely.

> (b) Update Boost to profit from C++11 support in the remaining libraries.
> (c) Keep using boost::filesystem until we update to C++17 but at least use
>     the std-compatible API for it (of course, we don't have any choice if
>     we upgrade Boost anyhow).

Those are really low on my priority list.