Remove C++11 in CI response Boost Math/Multiprecision deprecate C++11 in 2023 about wide-integer HOT 2 CLOSED

Will you update the code to take advantage of C++14 features? The main one - I found - was return type deduction improvements, meaning far less use of decltype(complicated-expression-duplicating-body-of-function) in function signatures, replaced with auto. Much nicer!

from wide-integer.

Will you update the code to take advantage of C++14 features? The main one - I found - was return type deduction improvements

Yes. I have decided to do this. This is a tough choice since it means actually deprecating C++11.

Hi John (@johnmcfarlane) I am glad you asked. I do try to modernize the code (yet honestly I struggle a bit with that).

Some improved features include that (also) interest me (and are interesting for this library) include:

• The one you mention (auto return type deduction)
• Relaxed constraints on constexpr function complexity.
• And this one surprised me but enable_if_t which I had thought was in C++17. It saves typing in templates but is actually available in 14.

I would have wanted constexpr-if, but that comes with 17.

Sometimes, I think you might have made the right choice, going straight away to 20 in cnl, as this saves a lot of headache. But I had insisted on some historical embedded applicability. It's hard to know if that even did any good instead of jumping to 20. I will, however, probably remain at 14 for a while and slowly-but-surely try to modernize. I'd like to keep supporting GCC5 (as my avr platforms need this). Most of this is OK in GCC5's c++11 interpretationi and even still works on GCC4.8's -std=c++1y.

So in a word, I'll bump up to 14 and subsequently try to modernize.

Again, I'm glad you asked. Thanks John!

from wide-integer.