Re: [lmi] New clang errors fixes

[Greg Chicares]

On 2017-09-17 17:35, Vadim Zeitlin wrote:
> 
>  I tried to build the latest sources with clang, as part of my tests, and
> it turns out that there are 2 new errors: one due to the use of
> non-constexpr std::ldexp() in the initialization of a constexpr variable in
> bourn_cast.hpp and another one (but occurring thrice) due to the use of
> deprecated std::auto_ptr<> in boost/regex.hpp.
> 
>  I've fixed both of them in https://github.com/vadz/lmi/pull/59

Let's consider std::ldexp() first:

https://github.com/vadz/lmi/pull/59/commits/72b38891924db39a5b07cec56b4e39e9a4414875

-    constexpr From limit = std::ldexp(From(1), to_traits::digits);
+    static From const limit = std::ldexp(From(1), to_traits::digits);

As the commit message remarks, that partially reverts this earlier change:

https://github.com/vadz/lmi/commit/15edd3b9f8a1847252a3a38ab29796104da3253b

-    static From const limit = std::ldexp(From(1), to_traits::digits);
+    constexpr From limit = std::ldexp(From(1), to_traits::digits);

whose commit message refers to this post:
  http://lists.nongnu.org/archive/html/lmi/2017-08/msg00068.html
which says that change was needed for gcc-6.3.0 and -std=c++17 as used
for production currently.

Thus, we're oscillating between two expressions, one of which is rejected
by our chosen version of gcc, and the other, by clang. It does seem that
the expression gcc accepts was an extension that seemed reasonable at the
time, but from which the evolving sense of the Committee now diverges:

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3788.html#2013
| This standard explicitly requires that certain standard library functions
| are constexpr [dcl.constexpr]. An implementation shall not declare any
| standard library function signature as constexpr except for those where
| it is explicitly required.

If it can't be static and it can't be constexpr, then is this:
+    From const limit = std::ldexp(From(1), to_traits::digits);
the best we can do to express the intention and help the compiler optimize?
Or should we write our own function, e.g.:

-    constexpr From limit = std::ldexp(From(1), to_traits::digits);
+    constexpr From limit = const_ldexp(From(1), to_traits::digits);

? All we're trying to do is raise two to a representable power. Is there
a clean way to do that within the intersection of both compilers' constexpr
rules (and perhaps msvc's too, if reasonable)? Iteration? Recursion? Table
lookup? Bitwise manipulation of an array of sizeof(long double) bits, with
reinterpret_cast<long double>?

As for std::auto_ptr<>, I guess we're stuck with it as long as we depend
on boost headers that use it. We could insert pragmata into our code
directly wherever needed, as is done here.
  
https://github.com/vadz/lmi/pull/59/commits/f799027a247dbd30e8eddf3e9d5804e7b8064c4d
or...

> Alternatively, we could have a wrapper header for boost/regex.hpp, but this
> doesn't seem useful from a long term perspective as we know that we will
> replace it with std::regex sooner or later

I like that idea. That we'll eventually replace it strikes me as an
argument in favor of this approach: it comes with its own disposal bag,
as it were, so that we can more easily and cleanly discard it later
instead of spending energy to find and remove every pragma.

BTW, I also considered:
  #define auto_ptr unique_ptr
but it's hard to guess what risks that might entail.