I'm quite new to this mailing list and this topic is therefore very
interesting as it show the opinion of various people contributing to boost.
When I'm looking for a library for my - professional - projects, I tend to
put more interest into libraries that leverage new parts of the standard.
Firstly, it is a very good way to push for a more modern codebase and
improve my and my coworkers knowledge of a more future-proof way of using
C++. Don't underestimate the importance of learning. Secondly, people
dealing with old codebases are less likely to look for new libraries. They
usually mostly maintain code or refactor one piece at a time, but tend to
use already existing libraries, or internal ones: new libraries are used
for new, up-to-date projects. Don't develop stuff for people who don't need
it. Thirdly, if you wait for a standard to be mature to start developing
around it, it's going to be outdated by the time your library is fit for
production.
I'd be very interested to know what other, more experienced people think
about all this.
Obviously if new libraries are able to be compatible with more compilers,
it is a good thing, but remember that if we want to have people using
recent standards, then we have to make them relevant.
On Dec 19, 2018 21:40, "Marc Glisse via Boost"
- C++17 compiler that supports constexpr if statements. There are a fair amount of calculations done at compile-time which would require messy SFINAE hacks to make this C++14-compatible.
I know my position is unpopular, but I don't think this is a good tradeoff. Supporting C++11 certainly requires more work on the author's part but that is a finite investment.
Writing it may be a "finite" investment, but maintaining the resulting, way more complicated code is not. And I am not even counting the cases where this has an impact on the API.
The return on this is a practically unbounded amount of utility, as the number of users is normally expected to greatly outnumber the amount of authors (1 in this case). In fact you could argue that there is infinite utility in laboring to produce "messy SFINAE hacks", because otherwise users of C++14 and C++11 cannot use the library at all. Most users only care that the library works, and are unaffected by the particulars of the sausage-making.
Don't underestimate the importance of keeping the author of the library motivated. If supporting crappy old tools makes them lose the will to keep improving the library, we end up with one more unmaintained boost package...
In general, I feel like it is a good engineering practice for Boost libraries to only require C++14 or C++17 when absolutely necessary. In
Why stop at C++11? Why not stick to C?
this case it does not seem necessary. This year's developer surveys indicate that C++11 has the most widespread use:
https://www.jetbrains.com/research/devecosystem-2018/cpp/
https://isocpp.org/files/papers/CppDevSurvey-2018-02-summary.pdf
It seems like doing the more verbose C++11-style SFINAE is worth it, to have access to the larger base of C++ users. This opinion is my own, and I will note that (roughly speaking) the Boost library policy does not currently mandate support for any specific versions of C++.
The survey is about what people were using several months ago for all kinds of projects, including maintaining legacy code bases. However, we are interested in - what people will be using by the time the library has been reviewed and released (say a couple years) - projects that are likely to introduce a dependency to some new external library Both introduce a strong bias towards more recent tools and standards. -- Marc Glisse _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost