I'm considering bumping up the C++ language requirement for Boost.URL from C++11 to C++14. I have concerns about doing this, because it affects all my downstream libraries (HTTP.Proto, HTTP.IO, Websocket.Proto, Websocket.IO, and any examples or complete clients/servers that I write). My main fear is that there are still a considerable number of individuals or corporations who, for whatever reason, cannot build with -std=c++14 or later despite having access to newer compilers. I don't mind if there is a small percentage of loss but I do mind if 20% or more of potential users will be locked out. The questions are: 1. Would you or your company be prevented from using Boost.URL if it required C++14? 2. Do you know any other organizations who cannot use C++14 or later? 3. Do you know of any regional or global metrics on who _cannot_ use libraries which require C++14? See also, this reddit thread on r/cpp: https://www.reddit.com/r/cpp/comments/w6zuo5/c11_or_require_c14/ -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco
I work for corporation that is pretty pragmatic about these things. We like to use the newest toys that modern c++ gives us, but since we need to support older versions of macOS, we are limited by what we can use for the lowest supported deployment target. Given that: Until very recently we used c++17, but with a set of standard library features that was off-limits. Examples of these are things like std::variant (because std::bad_variant_access requires 10.14), std::filesystem (requires 10.15 for std::filesystem_error). We've recently started using c++20, which works fine for all the language features - even if not all the library features are supported. In short: What I tihnk is relevant is is which library features you depend on. Compilers are easily updated, without much risk, but if you depend on library features with a compiled component, you'd need to be aware of which OS-version supports it. macOS is usually the lowest common denominator in this. On Sun, 2022-07-24 at 10:09 -0700, Vinnie Falco via Boost-users wrote:
I'm considering bumping up the C++ language requirement for Boost.URL from C++11 to C++14. I have concerns about doing this, because it affects all my downstream libraries (HTTP.Proto, HTTP.IO, Websocket.Proto, Websocket.IO, and any examples or complete clients/servers that I write).
My main fear is that there are still a considerable number of individuals or corporations who, for whatever reason, cannot build with -std=c++14 or later despite having access to newer compilers. I don't mind if there is a small percentage of loss but I do mind if 20% or more of potential users will be locked out.
The questions are:
1. Would you or your company be prevented from using Boost.URL if it required C++14?
2. Do you know any other organizations who cannot use C++14 or later?
3. Do you know of any regional or global metrics on who _cannot_ use libraries which require C++14?
See also, this reddit thread on r/cpp:
https://www.reddit.com/r/cpp/comments/w6zuo5/c11_or_require_c14/
On Sun, 24 Jul 2022 at 18:09, Vinnie Falco via Boost-users < boost-users@lists.boost.org> wrote:
I'm considering bumping up the C++ language requirement for Boost.URL from C++11 to C++14. I have concerns about doing this, because it affects all my downstream libraries (HTTP.Proto, HTTP.IO, Websocket.Proto, Websocket.IO, and any examples or complete clients/servers that I write).
My main fear is that there are still a considerable number of individuals or corporations who, for whatever reason, cannot build with -std=c++14 or later despite having access to newer compilers. I don't mind if there is a small percentage of loss but I do mind if 20% or more of potential users will be locked out.
The questions are:
1. Would you or your company be prevented from using Boost.URL if it required C++14?
2. Do you know any other organizations who cannot use C++14 or later?
3. Do you know of any regional or global metrics on who _cannot_ use libraries which require C++14?
See also, this reddit thread on r/cpp:
https://www.reddit.com/r/cpp/comments/w6zuo5/c11_or_require_c14/
-- Regards, Vinnie
Follow me on GitHub: https://github.com/vinniefalco _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
Answer to all three questions is NO. That is, requiring C++14 would be fine for me and my organisation. Regards, Pete
Hi, from our point of view: On Sun, 24 Jul 2022 at 19:12, Vinnie Falco via Boost-users < boost-users@lists.boost.org> wrote:
The questions are:
1. Would you or your company be prevented from using Boost.URL if it required C++14?
No, c++14 is fine for us: we are already on c++17 and aiming for c++20 by the end of the year.
2. Do you know any other organizations who cannot use C++14 or later?
3. Do you know of any regional or global metrics on who _cannot_ use
No, the other groups we work with are already using c++17. libraries which require C++14? No idea, sorry. Ciao, .Andrea
Here we are in C++17. And no to all 3 questions. Best regards, Christophe On 24/07/2022 19:09, Vinnie Falco via Boost-users wrote:
I'm considering bumping up the C++ language requirement for Boost.URL from C++11 to C++14. I have concerns about doing this, because it affects all my downstream libraries (HTTP.Proto, HTTP.IO, Websocket.Proto, Websocket.IO, and any examples or complete clients/servers that I write).
My main fear is that there are still a considerable number of individuals or corporations who, for whatever reason, cannot build with -std=c++14 or later despite having access to newer compilers. I don't mind if there is a small percentage of loss but I do mind if 20% or more of potential users will be locked out.
The questions are:
1. Would you or your company be prevented from using Boost.URL if it required C++14?
2. Do you know any other organizations who cannot use C++14 or later?
3. Do you know of any regional or global metrics on who _cannot_ use libraries which require C++14?
See also, this reddit thread on r/cpp:
https://www.reddit.com/r/cpp/comments/w6zuo5/c11_or_require_c14/
On Sun, Jul 24, 2022 at 10:09 AM Vinnie Falco
I'm considering bumping up the C++ language requirement for Boost.URL from C++11 to C++14.
So, here is some fantastic news. My motivation for raising the language requirement in Boost.URL was for better support for constexpr, as I wanted to improve the design of its parsing components. The older design didn't compose very well, didn't allow for run-time stateful grammars, and was lacking generic abstractions which used optional, tuple, and variant. The new design relied on declaring constexpr auto variables and needed a constexpr tuple which was unavailable in C++11. I noticed on reddit that there are still reports from users who cannot move to C++14 for various reasons, see: https://www.reddit.com/r/cpp/comments/w6zuo5/c11_or_require_c14/ I figured out a solution that kept the nice syntax with constexpr but also worked in C++11, which was to use a "thin tuple" written by Damian Jarek for beast and modified to be constexpr as an implementation detail, while using the non-constexpr C++11 "real tuple" to return results (which doesn't need to be constexpr). Now at the risk of inviting a ton of bikeshedding and questions like "why didn't you use Spirit" (please save it for the review which is in 15 days) I was able to throw out an entire page full of annoying parsing code and replace it with this: /** Rule for fragment-part @par BNF @code fragment-part = [ "#" fragment ] fragment = *( pchar / "/" / "?" ) @endcode @par Specification @li <a href="https://datatracker.ietf.org/doc/html/rfc3986#section-3.5" >3.5. Fragment (rfc3986)</a> */ constexpr auto fragment_part_rule = grammar::optional_rule( grammar::sequence_rule( grammar::char_rule( '#' ), pct_encoded_rule( pchars + '/' + '?' ) ) ); So it seems that I was able to dance my way around the constexpr limitations. I'm not sure how many more years I'll be able to do this, but I am happy that I can stay on C++11 for now. Some people think this is a form of self-torture but I really have not yet felt much pain from missing out on newer things. Thanks to mp11, variant2, and a few other Boost "polyfills" C++11 can be quite comfortable. I think this is great news! Thanks to everyone who provided feedback, it was very helpful and supportive. Regards
participants (6)
-
Andrea Bocci -
Christophe B -
Dominique Devienne -
Martijn Otto -
Peter Barker -
Vinnie Falco