Re: [lmi] Don't initialize constexpr variable with std::ldexp()

[Greg Chicares]

On 2017-04-24 16:51, Vadim Zeitlin wrote:
> On Mon, 24 Apr 2017 16:37:55 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2017-04-24 16:16, Vadim Zeitlin wrote:
> GC> > On Mon, 24 Apr 2017 15:25:48 +0000 Greg Chicares <address@hidden> wrote:
> GC> > 
> GC> > GC> With this patch, does the 'bourn_cast_test.cpp' unit test compile 
> and
> GC> > GC> report zero errors with these other two compilers?
> GC> > 
> GC> >  Yes, the test passes with both gcc and clang (and sorry, I meant to say
> GC> > this in my previous message but after rereading it I see that I forgot 
> to
> GC> > include it).
> GC> 
> GC> I think you meant
> GC> - the test passes with both gcc and clang
> GC> + the test passes with both msvc and clang
> 
>  No, for once I did write what I meant: the test (still) passes with gcc
> and (now also) passes with clang. I didn't test with MSVC because I didn't
> think you'd be interested in neither the result of the test nor,
> especially, in fixing any possible problems with it, but I could do if
> you'd like to.

As far as I can remember, lmi builds with MSVC except for 'any_member',
which it defectively refuses to compile--and which can't be made to work
except by replacing a great deal of template goodness with macro badness.
(Paragraph break so that you can explain how poorly I've remembered....)

It would be good to know whether at least lmi's unit tests (except for
'any_member_test') build and report zero errors for msvc. I'd especially
like to know whether the very recent 'bourn_cast_test' does.

BTW, does LMI_MSVCRT serve any purpose any more? It's used only in
'numeric_io*', to work around printf() problems in the msw system C RTL
like missing support for "%Lf" and formatting infinity as "1.#INF". The
mingw* toolchains work around that with libmingwex. Does msvc now use an
updated C RTL that doesn't have these defects, so that these LMI_MSVCRT
workarounds can be expunged?