[feature request] support C++11

[biojppm]

Thanks for your thorough work!

Would you consider accepting a MR for supporting C++11? if constexpr is really handy, but since it is not allowed in C++11, I could rewrite with SFINAE. But the code would be uglier and less readable as a result.

If that would be too much for you, maybe having a permanent cpp11 branch would do?

[jk-jeon]

I think if constexpr would not be the only issue. There are lots of terse static_assert's and things like std::is_same_v, and also I'm not sure if using lambdas in constexpr contexts is allowed in C++11, and also I'm not sure about static constexpr global variables defined in headers. In subprojects (which are not needed for actual usage of this library), there are also things like std::optional and std::string_view as well.

But if possible, C++11 support would be nice and I would very much appreciate it if you can work on that. (And I prefer to have it in a separate branch😊)

BTW, please be aware that this library is not yet production-ready and API will be overhauled, and also I cannot work on it for a while because the fall quarter has begun and I have to turn my mindset back into my major.

Thanks!

[sirinath]

At 1st glance this implementation is not using newer C++ features: https://github.com/abolz/Drachennest/blob/master/src/dragonbox.cc

I am not sure it they perform the same in terms of speed and memory use though.

[jk-jeon]

Alexander's implementation is not very different from mine I believe. He stripped off many metaprogramming nonsenses and hard-coded lots of constexpr-computed constants. Also he provided an improved string generation routine which probably performs better than mine at the cost of guaranteeing a weaker contract.

But what @biojppm is interested in is probably string-to-float conversion rather than float-to-string conversion as far as I understand, so possibly Dragonbox is pretty irrelevant to him.

[sirinath]

@expnkx

I am less interested in what version of the language is used as long as:

1. the algorithm is correct
2. the algorithm is the fastest possible or fastest known for the task
3. the code is easy to understand
4. the code is such that it is easy to port to different languages

Even if C++20 is used if the meta programming stuff can be cut down or simplified this would be most welcome.