Future of C++ and Boost

Vinnie Falco

19 Apr 2022 19 Apr '22

2:42 p.m.

It might be interesting to think about where C++ and Boost will be in the next 20 years and in the next 50 years. There has been an explosion of research and development into new programming languages (Rust being the most visible example). C++ is hardly the most popular language (Python is, if the TIOBE index is to be believed). But C++ is an essential language because it occupies the unique position of being as close as possible to assembly language while remaining high level. The zero-cost abstractions, metaprogramming, and powerful compositional tools of C++ still have no competitors and they are unlikely to have them any time soon. This doesn't necessarily mean that C++ is good for everything; there's an opportunity cost for all this. C++ code is generally more complex, harder to read, and harder to write than other code. Other languages are much better suited for certain tasks. No one should be implementing a content-driven website using Asio and Beast for example. But for the things that C++ is good at, it excels at them. A recent reddit post [1] provided a decent list:: * games * databases * high frequency trading * search (Google/Bing/DuckDuckGo) * web browsers (Chrome/Safari/Edge) * virtual reality headsets (Facebook) * distributed systems at big tech companies (Google/Microsoft/Facebook) * low level libraries (machine learning libraries like tensorflow and pytorch) * compilers, virtual machines, interpreters (JVM/gcc/LLVM) * robotics & hardware (ex: self driving cars, planes, missiles, space ships, etc) My opinion is that wg21 (the C++ standards committee) has been growing increasingly out of touch with the needs of the larger C++ community. Not necessarily out of malice, but because the bureaucratic process of the committee does not align the incentives of its members with users. I predict that we will see the C++ standard library become increasingly irrelevant by not only failing to produce stable things that people want, but also by not even keeping up feature-wise with the library ecosystem of other languages. Where is Requests [2] for C++? Python has had this for over a decade. In case you think I'm exaggerating, look at this comment from Reddit: ...a major vendor is getting ready to release a product that does not allow user applications to directly access TCP sockets so the only way to get any network access is to go through their standard library which only supports backdoored HTTPS. This vendor of course is Apple, as can be seen in P1860R0 [4]. We should not expect that wg21 will be able to deliver an important feature such as networking in a form that will be usable or recognizable to non-committee members. What does this mean for C++ and Boost? I believe there is a significant opportunity for Boost to step in and become the rational collection of actually useful libraries that the C++ standard library is not. We already have networking, some protocols, and JSON. We (the existing Boost authors and contributors) might consider looking to the list above of industries that use C++, and focus our efforts more towards providing libraries that enhance those industries. Perhaps by reaching out to leaders in those fields we might establish working relationships and build, say, the next Boost.Tensorflow or something like that. I don't know. Oh, and add "cryptocurrency" to the list above. C++ is the language of blockchain, because performance matters. What do you think? Thanks Vinnie [1] https://www.reddit.com/r/cpp/comments/u5vjni/comment/i54qbzq [2] https://docs.python-requests.org/en/latest/ [3] https://www.reddit.com/r/cpp/comments/u6z8gr/comment/i5caxr6 [4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1860r0.html

Show replies by date

William Linkmeyer

19 Apr 19 Apr

10:28 p.m.

+1 Although, I feel that there should be an *attempt* to make C++ libraries easy enough to use for anything. (For example, say, use asio & beast for websites. I can dream, okay?) WL

...

On Apr 19, 2022, at 10:42 AM, Vinnie Falco via Boost wrote:

It might be interesting to think about where C++ and Boost will be in the next 20 years and in the next 50 years. There has been an explosion of research and development into new programming languages (Rust being the most visible example). C++ is hardly the most popular language (Python is, if the TIOBE index is to be believed). But C++ is an essential language because it occupies the unique position of being as close as possible to assembly language while remaining high level. The zero-cost abstractions, metaprogramming, and powerful compositional tools of C++ still have no competitors and they are unlikely to have them any time soon.

This doesn't necessarily mean that C++ is good for everything; there's an opportunity cost for all this. C++ code is generally more complex, harder to read, and harder to write than other code. Other languages are much better suited for certain tasks. No one should be implementing a content-driven website using Asio and Beast for example. But for the things that C++ is good at, it excels at them. A recent reddit post [1] provided a decent list::

* games * databases * high frequency trading * search (Google/Bing/DuckDuckGo) * web browsers (Chrome/Safari/Edge) * virtual reality headsets (Facebook) * distributed systems at big tech companies (Google/Microsoft/Facebook) * low level libraries (machine learning libraries like tensorflow and pytorch) * compilers, virtual machines, interpreters (JVM/gcc/LLVM) * robotics & hardware (ex: self driving cars, planes, missiles, space ships, etc)

My opinion is that wg21 (the C++ standards committee) has been growing increasingly out of touch with the needs of the larger C++ community. Not necessarily out of malice, but because the bureaucratic process of the committee does not align the incentives of its members with users. I predict that we will see the C++ standard library become increasingly irrelevant by not only failing to produce stable things that people want, but also by not even keeping up feature-wise with the library ecosystem of other languages. Where is Requests [2] for C++? Python has had this for over a decade.

In case you think I'm exaggerating, look at this comment from Reddit:

...a major vendor is getting ready to release a product that does not allow user applications to directly access TCP sockets so the only way to get any network access is to go through their standard library which only supports backdoored HTTPS.

This vendor of course is Apple, as can be seen in P1860R0 [4]. We should not expect that wg21 will be able to deliver an important feature such as networking in a form that will be usable or recognizable to non-committee members.

What does this mean for C++ and Boost? I believe there is a significant opportunity for Boost to step in and become the rational collection of actually useful libraries that the C++ standard library is not. We already have networking, some protocols, and JSON. We (the existing Boost authors and contributors) might consider looking to the list above of industries that use C++, and focus our efforts more towards providing libraries that enhance those industries. Perhaps by reaching out to leaders in those fields we might establish working relationships and build, say, the next Boost.Tensorflow or something like that. I don't know.

Oh, and add "cryptocurrency" to the list above. C++ is the language of blockchain, because performance matters.

What do you think?

Thanks

Vinnie

[1] https://www.reddit.com/r/cpp/comments/u5vjni/comment/i54qbzq

[2] https://docs.python-requests.org/en/latest/

[3] https://www.reddit.com/r/cpp/comments/u6z8gr/comment/i5caxr6

[4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1860r0.html

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Timothy Keitt

20 Apr 20 Apr

3:02 p.m.

I'm just a hobbyist (I use C++ wrapped in R for my research and exploration) but my dream is something like julia (https://julialang.org/) but with modern C++ syntax. I have really enjoyed the recent metaprogramming additions to C++ and would love to have that in an interactive environment with incremental jit. (I know this can be kind of done now but its not like using R Studio or other nice user platforms.) BTW, C++ is found in high performance scientific computing, but not as often as Fortran and C. TK On Tue, Apr 19, 2022 at 5:28 PM William Linkmeyer via Boost < boost@lists.boost.org> wrote:

...

+1

Although, I feel that there should be an *attempt* to make C++ libraries easy enough to use for anything.

(For example, say, use asio & beast for websites. I can dream, okay?)

WL

...
On Apr 19, 2022, at 10:42 AM, Vinnie Falco via Boost < boost@lists.boost.org> wrote:

It might be interesting to think about where C++ and Boost will be in the next 20 years and in the next 50 years. There has been an explosion of research and development into new programming languages (Rust being the most visible example). C++ is hardly the most popular language (Python is, if the TIOBE index is to be believed). But C++ is an essential language because it occupies the unique position of being as close as possible to assembly language while remaining high level. The zero-cost abstractions, metaprogramming, and powerful compositional tools of C++ still have no competitors and they are unlikely to have them any time soon.

This doesn't necessarily mean that C++ is good for everything; there's an opportunity cost for all this. C++ code is generally more complex, harder to read, and harder to write than other code. Other languages are much better suited for certain tasks. No one should be implementing a content-driven website using Asio and Beast for example. But for the things that C++ is good at, it excels at them. A recent reddit post [1] provided a decent list::

* games * databases * high frequency trading * search (Google/Bing/DuckDuckGo) * web browsers (Chrome/Safari/Edge) * virtual reality headsets (Facebook) * distributed systems at big tech companies (Google/Microsoft/Facebook) * low level libraries (machine learning libraries like tensorflow and pytorch) * compilers, virtual machines, interpreters (JVM/gcc/LLVM) * robotics & hardware (ex: self driving cars, planes, missiles, space ships, etc)

My opinion is that wg21 (the C++ standards committee) has been growing increasingly out of touch with the needs of the larger C++ community. Not necessarily out of malice, but because the bureaucratic process of the committee does not align the incentives of its members with users. I predict that we will see the C++ standard library become increasingly irrelevant by not only failing to produce stable things that people want, but also by not even keeping up feature-wise with the library ecosystem of other languages. Where is Requests [2] for C++? Python has had this for over a decade.

In case you think I'm exaggerating, look at this comment from Reddit:

...a major vendor is getting ready to release a product that does not allow user applications to directly access TCP sockets so the only way to get any network access is to go through their standard library which only supports backdoored HTTPS.

This vendor of course is Apple, as can be seen in P1860R0 [4]. We should not expect that wg21 will be able to deliver an important feature such as networking in a form that will be usable or recognizable to non-committee members.

What does this mean for C++ and Boost? I believe there is a significant opportunity for Boost to step in and become the rational collection of actually useful libraries that the C++ standard library is not. We already have networking, some protocols, and JSON. We (the existing Boost authors and contributors) might consider looking to the list above of industries that use C++, and focus our efforts more towards providing libraries that enhance those industries. Perhaps by reaching out to leaders in those fields we might establish working relationships and build, say, the next Boost.Tensorflow or something like that. I don't know.

Oh, and add "cryptocurrency" to the list above. C++ is the language of blockchain, because performance matters.

What do you think?

Thanks

Vinnie

[1] https://www.reddit.com/r/cpp/comments/u5vjni/comment/i54qbzq

[2] https://docs.python-requests.org/en/latest/

[3] https://www.reddit.com/r/cpp/comments/u6z8gr/comment/i5caxr6

[4] < http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1860r0.html>

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Stefan Seefeld

6:45 p.m.

On Wed, Apr 20, 2022 at 11:03 AM Timothy Keitt via Boost < boost@lists.boost.org> wrote:

...

I'm just a hobbyist (I use C++ wrapped in R for my research and exploration) but my dream is something like julia (https://julialang.org/) but with modern C++ syntax. I have really enjoyed the recent metaprogramming additions to C++ and would love to have that in an interactive environment with incremental jit. (I know this can be kind of done now but its not like using R Studio or other nice user platforms.) BTW, C++ is found in high performance scientific computing, but not as often as Fortran and C.

If you are looking for a high-level language with support for metaprogramming, I suggest you look into Python. You can even write Python bindings for C++ using Boost.Python ! (Sorry, couldn't resist.) -- ...ich hab' noch einen Koffer in Berlin...

Michael Caisse

22 Apr 22 Apr

1:49 a.m.

On 4/20/22 08:02, Timothy Keitt via Boost wrote:

...

I'm just a hobbyist (I use C++ wrapped in R for my research and exploration) but my dream is something like julia (https://julialang.org/)

<snip> Please don't top post. https://www.boost.org/community/policy.html#quoting Thanks! michael-with-his-mod-hat

Hans Dembinski

25 Apr 25 Apr

9:08 a.m.

...

On 20. Apr 2022, at 17:02, Timothy Keitt via Boost wrote:

I'm just a hobbyist (I use C++ wrapped in R for my research and exploration) but my dream is something like julia (https://julialang.org/) but with modern C++ syntax. I have really enjoyed the recent metaprogramming additions to C++ and would love to have that in an interactive environment with incremental jit. (I know this can be kind of done now but its not like using R Studio or other nice user platforms.) BTW, C++ is found in high performance scientific computing, but not as often as Fortran and C.

This is getting off-topic, but let me comment as a fellow data scientist and Boost developer... Julia was created for your use case, so I am not sure what you don't like about it (I never looked into Julia). I personally find less need to write C++ code nowadays, since my preferred language Python has the Numba JIT compiler, which produces very fast numerical code. In the past, I was writing C++ to accelerate the crunchy bits. As Stefan said, Boost.Python is great when you need to combine C++ and Python, although its clone pybind11 is more popular these days and has more features. The niche for C++ in my view is large high-performance applications with nice high-level APIs and close-to-the-metal implementations. But also numerical libraries like Eigen make very good use of these capabilities. "modern C++ syntax": It is interesting that you say that, because many people think that C++ has a rather inconsistent and archaic syntax because of all the compromises one has to make in regard to backward compatibility. "C++ is found in high performance scientific computing, but not as often as Fortran and C." Old specialised numerical libraries are not replaced. SciPy and many other libs are still using FORTRAN and C implementations written in the 80'ies. They work and the bugs have been ironed out, plus, the code often is a horrible mess (goto's everywhere) that you cannot easily port to a modern language. Scientists, which are not programmers, are also often turned off by the complexity of C++. They don't need the type system very much, which is a strength of C++ but also adds a lot to the learning curve. Why anyone would prefer programming in C over C++ is a mystery to me, though, automatic memory management with std::unique_ptr and friends alone is such a boon. The C++ interface provided by Boost.Python and pybind11 is much easier to use than the original Python C API exactly for that reason. Best regards, Hans

William Linkmeyer

3:40 p.m.

I’m going to try to refocus this thread, because I think this thread could be important, with a question: What is the simplest, most relevant library or feature — or library improvement — that C++ or Boost is missing? Some options, previously stated, include: * graphics APIs * scientific computing APIs * language interoperability (esp. Python) * HFT APIs * Syntax simplicity * machine learning APIs Personally, I have a quite large IOT framework which could be made open-source or eventually merged into boost. However, it would require a lot of refactoring and rethinking. It is much more of a standalone system or an orchestration of discrete tools than a library. And it’s only roughly 1/3 comprised of C++; the rest being kernel modules, shell scripts and bind9/dnsmasq/netconf/rc/etc hooks. In other words, if the interest is there, I could sit down for a few months and turn this into a library. Although, I have no idea *what* boost is looking for or what may be helpful. WL

...

On Apr 25, 2022, at 5:08 AM, Hans Dembinski via Boost wrote:

...
On 20. Apr 2022, at 17:02, Timothy Keitt via Boost wrote:

I'm just a hobbyist (I use C++ wrapped in R for my research and exploration) but my dream is something like julia (https://julialang.org/) but with modern C++ syntax. I have really enjoyed the recent metaprogramming additions to C++ and would love to have that in an interactive environment with incremental jit. (I know this can be kind of done now but its not like using R Studio or other nice user platforms.) BTW, C++ is found in high performance scientific computing, but not as often as Fortran and C.

This is getting off-topic, but let me comment as a fellow data scientist and Boost developer...

Julia was created for your use case, so I am not sure what you don't like about it (I never looked into Julia). I personally find less need to write C++ code nowadays, since my preferred language Python has the Numba JIT compiler, which produces very fast numerical code. In the past, I was writing C++ to accelerate the crunchy bits. As Stefan said, Boost.Python is great when you need to combine C++ and Python, although its clone pybind11 is more popular these days and has more features. The niche for C++ in my view is large high-performance applications with nice high-level APIs and close-to-the-metal implementations. But also numerical libraries like Eigen make very good use of these capabilities.

"modern C++ syntax": It is interesting that you say that, because many people think that C++ has a rather inconsistent and archaic syntax because of all the compromises one has to make in regard to backward compatibility.

"C++ is found in high performance scientific computing, but not as often as Fortran and C." Old specialised numerical libraries are not replaced. SciPy and many other libs are still using FORTRAN and C implementations written in the 80'ies. They work and the bugs have been ironed out, plus, the code often is a horrible mess (goto's everywhere) that you cannot easily port to a modern language. Scientists, which are not programmers, are also often turned off by the complexity of C++. They don't need the type system very much, which is a strength of C++ but also adds a lot to the learning curve.

Why anyone would prefer programming in C over C++ is a mystery to me, though, automatic memory management with std::unique_ptr and friends alone is such a boon. The C++ interface provided by Boost.Python and pybind11 is much easier to use than the original Python C API exactly for that reason.

Best regards, Hans

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Kostas Savvidis

5 May 5 May

2:26 p.m.

...

On Apr 25, 2022, at 18:40, William Linkmeyer via Boost wrote:

What is the simplest, most relevant library or feature — or library improvement — that C++ or Boost is missing?

There might be many nice things to have. But, I would argue that what Boost needs is a trimming and deprecation of ancient stuff. There are a million reasons why this cannot be done tomorrow, but if we are talking about a roadmap for 20 and 50 years then it might be a good time to think about it. First and foremost, adopt a timeframe now to get rid of stuff that has been later implemented in the standard library. I do not accept that the standard library is not good enough, as has been heard also in this thread, if that is indeed the conclusion then it's indeed time to get together for a beer, cry and hug, and switch to Python. Second, that such and such library will be deprecated by 2030 - and threaten that other libraries will de deprecated if they cannot get rid of the dependency (mpl!). In other words, boost needs to shrink not grow. Maybe someone should make a boost-lite with no ancient dependencies and weighting 10MB max? I conjecture that it would do magic to adoption by smaller sized projects. Cheers, Kostas

Mateusz Loskot

2:58 p.m.

On Thu, 5 May 2022 at 16:26, Kostas Savvidis via Boost wrote:

...

[...] In other words, boost needs to shrink not grow.

I mostly agree, but I'd say Boost needs to undergo a restructurisation to remain attractive to all generations of developers, maintainers and users. I can't see it happen unless we have separate superprojects: github.com/boostorg/boost (require>=C++17) github.com/boostorg/boost11 (>=C++11 ) and, if still relevant, perhaps: github.com/boostorg/boost03 As a maintainer, I'd like to be free to maintain a library only for e.g. boostorg/boost and forget about boostorg/boost11, or let new maintainer to take it over there. Best regards -- Mateusz Loskot, http://mateusz.loskot.net

Vinnie Falco

3 p.m.

On Thu, May 5, 2022 at 7:59 AM Mateusz Loskot via Boost wrote:

...

github.com/boostorg/boost (require>=C++17) github.com/boostorg/boost11 (>=C++11 )

Yep I like this - who is going to port Asio? Thanks

James E. King III

3:51 p.m.

On Thu, May 5, 2022 at 10:59 AM Mateusz Loskot via Boost wrote:

...

On Thu, 5 May 2022 at 16:26, Kostas Savvidis via Boost wrote:

...
[...] In other words, boost needs to shrink not grow.

I mostly agree, but I'd say Boost needs to undergo a restructurisation to remain attractive to all generations of developers, maintainers and users.

I can't see it happen unless we have separate superprojects:

github.com/boostorg/boost (require>=C++17) github.com/boostorg/boost11 (>=C++11 )

and, if still relevant, perhaps:

github.com/boostorg/boost03

As a maintainer, I'd like to be free to maintain a library only for e.g. boostorg/boost and forget about boostorg/boost11, or let new maintainer to take it over there.

About shrinking boost: I see no reason to have separate superprojects for different language levels. Why not simply have a concerted effort to remove C++03 support? If people still are using C++03 then they can use an older release of Boost until they make the transition. Stop testing it, stop saying it works, and allow C++11 in those libraries. The savings to CI time alone would be quite profound. I would like to see the floor move to C++11 at this point. In cases where the standard library has implemented something like what boost delivers in the C++11 standard, then it would also be reasonable to drop those boost libraries because, again, people can use an older release of Boost until they make the transition. If the project regularly claimed support for 3 back-revisions of language then with C++23 is released, C++20, C++17, C++14 would be "officially" supported and C++11 would be dropped. That simply means it is no longer tested or fixes made; people can use an older boost version until they make the transition. Having a hard-and-fast rule like this makes things way more predictable for all of us and all the consumers. About C++ in general (20/50 yrs): In comparison to other languages, C++ package management still seems like it is struggling. I guess you can use conan and cmake together but I haven't done enough to know how easy or difficult it is to do, and it looks like there are platform specific instructions for either. Having worked with python, javascript, perl and rust as well, the package management systems have their warts but generally make it a lot easier to consume external work and release work to others. It is a significant weakness in the ecosystem. - Jim

Niall Douglas

4:06 p.m.

On 05/05/2022 16:51, James E. King III via Boost wrote:

...

In comparison to other languages, C++ package management still seems like it is struggling. I guess you can use conan and cmake together but I haven't done enough to know how easy or difficult it is to do, and it looks like there are platform specific instructions for either. Having worked with python, javascript, perl and rust as well, the package management systems have their warts but generally make it a lot easier to consume external work and release work to others. It is a significant weakness in the ecosystem.

I gotta be honest, last year or two vcpkg "just works" and as far as I'm concerned C++ package management is a done deal. If you're reading that statement and thinking "what's he on about?", then I suggest go rebase your cmake projects onto vcpkg manifest mode, and once you've climbed the learning curve, I doubt you'll need to look back. Any perception by members of the C++ community that C++ package management isn't a done deal for the majority of use cases I think that's a training and learning issue. Even cross compiling with vcpkg for other targets via a cmake toolchain file "just works" now for most packages. I don't wish to do down other package managers such as conan or cpp-pm, but vcpkg has been very much seeing the benefit of full time employees working on it. I can even use it over a Samba networked drive now, which it previously used to die trying. Niall

Richard

4:58 p.m.

In article , Niall Douglas via Boost writes:

...

I gotta be honest, last year or two vcpkg "just works" and as far as I'm concerned C++ package management is a done deal.

I agree 100%. Here is a presentation I did on vcpkg and my experience: https://www.youtube.com/watch?v=gpBDHh47w-I I played with Conan. It was a fail. I played with Hunter and while I liked it, it was too CMake centric. -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Terminals Wiki http://terminals-wiki.org The Computer Graphics Museum http://ComputerGraphicsMuseum.org Legalize Adulthood! (my blog) http://LegalizeAdulthood.wordpress.com

Andrey Semashev

9:01 p.m.

On 5/5/22 19:06, Niall Douglas via Boost wrote:

...

I gotta be honest, last year or two vcpkg "just works" and as far as I'm concerned C++ package management is a done deal.

https://github.com/microsoft/vcpkg#telemetry

...

vcpkg collects usage data in order to help us...

At this point I don't want to read about it anymore. It has become a habit of mine to be suspicious about Microsoft products, open source or not, because they embed their probes in every piece of software they release. I can understand the need for a package manager on Windows, since it essentially doesn't have an "official" one. But I never understood why I would want one on Linux (most flavors of it) since there already is one. I'm probably missing something, but I don't understand this initiative to pull a package manager into every programming language, including C++.

Vinnie Falco

4:16 p.m.

On Thu, May 5, 2022 at 8:52 AM James E. King III via Boost wrote:

...

Why not simply have a concerted effort to remove C++03 support?

Not a bad idea in principle, but maybe you could ask Christopher Kohlhoff if he wants to drop C++03 support from Asio, and whether he wants to maintain this new, 3rd version of Asio? Thanks

James E. King III

4:36 p.m.

On Thu, May 5, 2022 at 12:16 PM Vinnie Falco wrote:

...

On Thu, May 5, 2022 at 8:52 AM James E. King III via Boost wrote:

...
Why not simply have a concerted effort to remove C++03 support?

Not a bad idea in principle, but maybe you could ask Christopher Kohlhoff if he wants to drop C++03 support from Asio, and whether he wants to maintain this new, 3rd version of Asio?

Thanks

I may not understand the concerns there, but in general what I was suggesting was: 1. Stop testing C++03 in CI 2. Stop advertising C++03 support in repositories 3. Make it clear that C++11 is required to use boost >= 1.8X 4. Close issues that involve C++03 specifically (likely not that many) 5. Allow repositories to accept C++11 compliant pull requests 6. Come up with a project-wide rule, for example that boost will support 3 back-revisions of C++ so the future is more predictable. Libraries do not need to immediately rework themselves. They simply no longer need to consider it broken when C++03 no longer builds properly. - Jim

Peter Dimov

6:32 p.m.

James E. King III wrote:

...

I may not understand the concerns there, but in general what I was suggesting was:

1. Stop testing C++03 in CI 2. Stop advertising C++03 support in repositories 3. Make it clear that C++11 is required to use boost >= 1.8X 4. Close issues that involve C++03 specifically (likely not that many) 5. Allow repositories to accept C++11 compliant pull requests 6. Come up with a project-wide rule, for example that boost will support 3 back-revisions of C++ so the future is more predictable.

Libraries do not need to immediately rework themselves.

They simply no longer need to consider it broken when C++03 no longer builds properly.

I agree with Jim's points above. This was my exact suggestion in the past, that we need to drop C++03 globally at the Boost level, and I only wrote up the policy by which individual libraries can do so https://pdimov.github.io/articles/phasing_out_cxx03.html when we failed to reach a consensus on the above points. The arguments in https://pdimov.github.io/articles/phasing_out_cxx03.html#_ongoing_costs_of_m... still stand. At this point we might as well move straight to C++14, it being the default on most not-yet-dead distros (with the notable exception of CentOS 7, I suppose.)

Mateusz Loskot

7:29 p.m.

On Thu, 5 May 2022 at 20:32, Peter Dimov via Boost wrote:

...

James E. King III wrote:

...
I may not understand the concerns there, but in general what I was suggesting was:

1. Stop testing C++03 in CI 2. Stop advertising C++03 support in repositories 3. Make it clear that C++11 is required to use boost >= 1.8X 4. Close issues that involve C++03 specifically (likely not that many) 5. Allow repositories to accept C++11 compliant pull requests 6. Come up with a project-wide rule, for example that boost will support 3 back-revisions of C++ so the future is more predictable.

Libraries do not need to immediately rework themselves.

They simply no longer need to consider it broken when C++03 no longer builds properly.

I agree with Jim's points above. This was my exact suggestion in the past, that we need to drop C++03 globally at the Boost level, and I only wrote up the policy by which individual libraries can do so

https://pdimov.github.io/articles/phasing_out_cxx03.html

It's a great policy and I'm surprised it's not been widely adopted. I'm grateful for it and I have made GIL follow it :) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Robert Ramey

11 May 11 May

10:19 p.m.

On 5/5/22 9:36 AM, James E. King III via Boost wrote:

...

On Thu, May 5, 2022 at 12:16 PM Vinnie Falco wrote:

...
On Thu, May 5, 2022 at 8:52 AM James E. King III via Boost wrote:

...
Why not simply have a concerted effort to remove C++03 support?

Not a bad idea in principle, but maybe you could ask Christopher Kohlhoff if he wants to drop C++03 support from Asio, and whether he wants to maintain this new, 3rd version of Asio?

Thanks

I may not understand the concerns there, but in general what I was suggesting was:

1. Stop testing C++03 in CI 2. Stop advertising C++03 support in repositories 3. Make it clear that C++11 is required to use boost >= 1.8X 4. Close issues that involve C++03 specifically (likely not that many) 5. Allow repositories to accept C++11 compliant pull requests 6. Come up with a project-wide rule, for example that boost will support 3 back-revisions of C++ so the future is more predictable.

Libraries do not need to immediately rework themselves.

They simply no longer need to consider it broken when C++03 no longer builds properly.

If I recall correctly, the boost "rules" are that a library submitted to boost must be conformant with the most recent version of the C++ standard. Assume the library gets accepted. Its then no required to be constantly upgraded to subsequent standards. Soooo a) Because specifies backward compatibility as a requirement, the library is guaranteed to compile and function in all subsequent versions of C++ b) Any subsequently added library is also guaranteed to compile and function in all version of C++. c) Any previously included libraries would have no such guarantee. But had the original library included such a library, it wouldn't pass it's tests which would make it extremely unlikely to be accepted as a boost library. Users of any conforming version of the C++ compiler can use any boost library going back the the very first one and expect it to compile and execute directly. (their might be some rare exceptions due to modern, funky syntax additions but one would have to study the subject). Users who do do not wish to have C++03 conforming code in their code base are free not to include it. One should be including code on a module by module basis so this would be trivial to do. 99% of users don't even look at the source code. The libraries which exceed 1% is likely due to the documentation being illegible. Note that people don't seem to have any problem using a venders std:: library with inaccessible source code. How do they know that it wasn't written in 2003 and tested with C++03? They don't the reason they bring it up with boost is that they have nothing else to do. We have this discussion every 5 years or so. It always goes nowhere because there is nowhere for it to go. Robert Ramey

...

- Jim

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

John Maddock

12 May 12 May

11:22 a.m.

...

If I recall correctly, the boost "rules" are that a library submitted to boost must be conformant with the most recent version of the C++ standard. Assume the library gets accepted. Its then no required to be constantly upgraded to subsequent standards. Soooo

a) Because specifies backward compatibility as a requirement, the library is guaranteed to compile and function in all subsequent versions of C++

b) Any subsequently added library is also guaranteed to compile and function in all version of C++.

Point of pedantry: that's not true at all, stuff get's deprecated and then removed. For example unary_function is deprecated in C++11 and removed in C++17, which has just hit for example: https://github.com/boostorg/container_hash/issues/22#issuecomment-1124205780 as gcc-12 starts enforcing this (msvc has done so for a while). There are plenty of other examples. Best, John.

Robert Ramey

3:03 p.m.

On 5/12/22 4:22 AM, John Maddock via Boost wrote:

...

...
If I recall correctly, the boost "rules" are that a library submitted to boost must be conformant with the most recent version of the C++ standard. Assume the library gets accepted. Its then no required to be constantly upgraded to subsequent standards. Soooo

a) Because specifies backward compatibility as a requirement, the library is guaranteed to compile and function in all subsequent versions of C++

b) Any subsequently added library is also guaranteed to compile and function in all version of C++.

Point of pedantry: that's not true at all, stuff get's deprecated and then removed.

I don't think it's pedantic. You're right. I had forgotten about these. I can say that over 20 years, I've never run across this with the serialization library which has a lot of lines of code. Were it to happen, I'd have to decide what kind of compatibility to maintain. Given that 03 isn't really testible these days, that might be the end of that. It's also very possible that one or more of these presented themselves and it so trivial to update that I forgot about it. All in all I don't think this should be a big issue.

...

For example unary_function is deprecated in C++11 and removed in C++17, which has just hit for example: https://github.com/boostorg/container_hash/issues/22#issuecomment-1124205780 as gcc-12 starts enforcing this (msvc has done so for a while).

There are plenty of other examples.

Best, John.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

John Maddock

4:55 p.m.

...

I don't think it's pedantic. You're right.

I had forgotten about these. I can say that over 20 years, I've never run across this with the serialization library which has a lot of lines of code. Were it to happen, I'd have to decide what kind of compatibility to maintain. Given that 03 isn't really testible these days, that might be the end of that.

It's also very possible that one or more of these presented themselves and it so trivial to update that I forgot about it.

All in all I don't think this should be a big issue.

Watch out - all of <codecvt> is deprecated in C++17, I think you're relying only on <local> and may be OK though... John.

Robert Ramey

6:30 p.m.

On 5/12/22 9:55 AM, John Maddock via Boost wrote:

...

...
I don't think it's pedantic. You're right.

I had forgotten about these. I can say that over 20 years, I've never run across this with the serialization library which has a lot of lines of code. Were it to happen, I'd have to decide what kind of compatibility to maintain. Given that 03 isn't really testible these days, that might be the end of that.

It's also very possible that one or more of these presented themselves and it so trivial to update that I forgot about it.

All in all I don't think this should be a big issue.

Watch out - all of <codecvt> is deprecated in C++17, I think you're relying only on <local> and may be OK though...

wow - that would be a big one. codecvt is the fundamental component to support wchar is it not? Does this mean that wchar is gone also? If so what replaced it? etc....

...

John.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Robert Ramey

6:34 p.m.

On 5/12/22 11:30 AM, Robert Ramey via Boost wrote:

...

On 5/12/22 9:55 AM, John Maddock via Boost wrote:

...

wow - that would be a big one. codecvt is the fundamental component to support wchar is it not? Does this mean that wchar is gone also? If so what replaced it? etc....

FWIW - I don't see any notice of such deprecation here: https://en.cppreference.com/w/cpp/header/codecvt Robert Ramey

...

...
John.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Marshall Clow

6:48 p.m.

On May 12, 2022, at 11:34 AM, Robert Ramey via Boost wrote:

...

On 5/12/22 11:30 AM, Robert Ramey via Boost wrote:

...
On 5/12/22 9:55 AM, John Maddock via Boost wrote:

...
wow - that would be a big one. codecvt is the fundamental component to support wchar is it not? Does this mean that wchar is gone also? If so what replaced it? etc....

FWIW - I don't see any notice of such deprecation here: https://en.cppreference.com/w/cpp/header/codecvt

Its in green - at the top: codecvt_utf8 https://en.cppreference.com/w/cpp/locale/codecvt_utf8 (C++11)(deprecated in C++17) — Marshall

Andrey Semashev

8:39 p.m.

On 5/12/22 21:48, Marshall Clow via Boost wrote:

...

On May 12, 2022, at 11:34 AM, Robert Ramey via Boost wrote:

...
On 5/12/22 11:30 AM, Robert Ramey via Boost wrote:

...
On 5/12/22 9:55 AM, John Maddock via Boost wrote:

...
wow - that would be a big one. codecvt is the fundamental component to support wchar is it not? Does this mean that wchar is gone also? If so what replaced it? etc....

FWIW - I don't see any notice of such deprecation here: https://en.cppreference.com/w/cpp/header/codecvt

Its in green - at the top: codecvt_utf8 https://en.cppreference.com/w/cpp/locale/codecvt_utf8 (C++11)(deprecated in C++17)

Also here: http://eel.is/c++draft/depr.locale.stdcvt#depr.codecvt.syn

Gavin Lambert

13 May 13 May

1:20 a.m.

On 13/05/2022 06:30, Robert Ramey wrote:

...

On 5/12/22 9:55 AM, John Maddock wrote:

...
Watch out - all of <codecvt> is deprecated in C++17, I think you're relying only on <local> and may be OK though...

wow - that would be a big one. codecvt is the fundamental component to support wchar is it not? Does this mean that wchar is gone also? If so what replaced it? etc....

wchar_t is still around (although char8_t and std::u8string are the new hotness), it's just the conversion functions that are deprecated. I guess you're just not supposed to convert anything any more. More seriously, AFAIK there's no plans to actually remove it until/unless an actual replacement gets standardised. But I think in the meantime they'd rather you use something like the ICU library for conversions instead. Although it wouldn't surprise me if, in not wanting to take a dependency on an external library (and not wanting to continue using an officially deprecated standard function), a lot of libraries/apps will write their own subtly-broken conversion routines instead...

Oliver Kowalke

5 May 5 May

6:23 p.m.

Vinnie Falco via Boost schrieb am Do., 5. Mai 2022, 18:16:

...

On Thu, May 5, 2022 at 8:52 AM James E. King III via Boost wrote:

...
Why not simply have a concerted effort to remove C++03 support?

Not a bad idea in principle, but maybe you could ask Christopher Kohlhoff if he wants to drop C++03 support from Asio, and whether he wants to maintain this new, 3rd version of Asio?

Thanks

...

This will probably never happen ... I'm still waiting for his promised re-factoring of boost::spawn().

Mateusz Loskot

7:26 p.m.

On Thu, 5 May 2022 at 17:51, James E. King III via Boost wrote:

...

On Thu, May 5, 2022 at 10:59 AM Mateusz Loskot via Boost wrote:

...
On Thu, 5 May 2022 at 16:26, Kostas Savvidis via Boost wrote:

...
[...] In other words, boost needs to shrink not grow.

I mostly agree, but I'd say Boost needs to undergo a restructurisation to remain attractive to all generations of developers, maintainers and users.

I can't see it happen unless we have separate superprojects:

github.com/boostorg/boost (require>=C++17) github.com/boostorg/boost11 (>=C++11 )

and, if still relevant, perhaps:

github.com/boostorg/boost03

As a maintainer, I'd like to be free to maintain a library only for e.g. boostorg/boost and forget about boostorg/boost11, or let new maintainer to take it over there.

About shrinking boost:

I see no reason to have separate superprojects for different language levels. Why not simply have a concerted effort to remove C++03 support?

Why not simply have a concerted effort to remove C++11/14? Well, we as a community need to make space for everyone, those who want 03, those who want 11, and those who aim higher. Like we did it for those who want Boost.Build and those who want CMake. Otherwise, we will end up whipping the cream, again, and nothing will happen, again. I can't see making the space (and making the Boost more inclusive) w/o separate superprojects. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

James E. King III

6 May 6 May

12:08 a.m.

On Thu, May 5, 2022 at 3:27 PM Mateusz Loskot via Boost wrote:

...

On Thu, 5 May 2022 at 17:51, James E. King III via Boost wrote:

...
On Thu, May 5, 2022 at 10:59 AM Mateusz Loskot via Boost wrote:

...
On Thu, 5 May 2022 at 16:26, Kostas Savvidis via Boost wrote:

...
[...] In other words, boost needs to shrink not grow.

I mostly agree, but I'd say Boost needs to undergo a restructurisation to remain attractive to all generations of developers, maintainers and users.

I can't see it happen unless we have separate superprojects:

github.com/boostorg/boost (require>=C++17) github.com/boostorg/boost11 (>=C++11 )

and, if still relevant, perhaps:

github.com/boostorg/boost03

As a maintainer, I'd like to be free to maintain a library only for e.g. boostorg/boost and forget about boostorg/boost11, or let new maintainer to take it over there.

About shrinking boost:

I see no reason to have separate superprojects for different language levels. Why not simply have a concerted effort to remove C++03 support?

Why not simply have a concerted effort to remove C++11/14?

Well, we as a community need to make space for everyone, those who want 03, those who want 11, and those who aim higher. Like we did it for those who want Boost.Build and those who want CMake.

Otherwise, we will end up whipping the cream, again, and nothing will happen, again.

I can't see making the space (and making the Boost more inclusive) w/o separate superprojects.

I disagree with you here. Past versions of Boost which are stable and released do support C++03. The work to support the language level has already been done and it is available for all to use. There is no good reason to saddle future development to it. This group as a whole needs to move forward. It is in the same state as I left it in 2018 to start my own company... a lack of consensus to make forward progress. Dropping C++03 and establishing a new baseline, and creating rules for backwards compatibility is what all other projects do. I see no reason for Boost to deviate. If there are people who cannot use C++11 for some reason, they can use older boost releases. We are not leaving anyone behind. They have options. It is up to us to move forward; it is up to them to decide if they also want to move forward. It is not our responsibility to be their savior for all things C++ if they decide not to embrace the future. As a point of comparison, I offer you this: - In Python there is a clear definition when a language level will no longer be supported: https://devguide.python.org/#status-of-python-branches - In node.js there is a clear definition when a language level will no longer be supported: https://nodejs.org/en/about/releases/ - In Ruby there is a clear definition when a language level will no longer be supported: https://endoflife.date/ruby - In Perl there is a clear definition when a language level will no longer be supported: https://endoflife.date/perl Now, you may argue that these are language levels and not libraries. I would counter that Boost is no ordinary library. Given the size and scope of the Boost C++ libraries they are an entire ecosystem unto their own. They deserve the same treatment as a language level. Therefore I would propose, again, that Boost officially adopt the philosophy that it establishes a support baseline of the current C++ language level and the prior three. This is VERY lenient in relation to the other links I posted. This means currently we have C++20 and we will officially support C++17, C++14, and C++11, to the extent a library is not specifically designed for a newer language level than that. I for one would enjoy updating Boost.CI and the 16 Boost libraries that I maintain to stop running C++03 tests through CI and stop claiming support for utterly ancient EOL compilers, as well as language levels. This is a small step forward. We should all consider taking it together. As a community we need to make progress in some capacity. In the past it has been impossible to achieve a consensus on things like this. We need to come together to move forward. In the lens of looking to where Boost will be in 20/50 years from you, this will go a long way to ensuring that the future of Boost is not saddled with impossible backwards compatibility matrices. We had these same discussions 5 years ago and ended up getting nowhere. We cannot let this happen again. - Jim

Gavin Lambert

1:33 a.m.

On 6/05/2022 12:08, James E. King III wrote:

...

I for one would enjoy updating Boost.CI and the 16 Boost libraries that I maintain to stop running C++03 tests through CI and stop claiming support for utterly ancient EOL compilers, as well as language levels.

As far as I was aware, it was already agreed several years back that maintainers of individual "leaf" libraries could decide to stop supporting pre-C++11 pretty much whenever they like (one or two versions of deprecation warning appreciated), and that new libraries did not need to be backwards compatible. It's a little murkier for libraries that are depended on by other libraries; there you had to get consensus from the downstream library maintainers to stop supporting pre-C++11 too, either simultaneously or earlier. I would personally argue that it makes sense now to move that forward to C++14 rather than C++11, but I don't think that's actually been formally discussed yet. There's a certain amount of resistance to "forcing changes" on libraries that don't really get touched year-to-year, because changes require work and have potential to introduce bugs. While there are some benefits to rewriting older code to remove workarounds and use more modern patterns (making future maintainability easier), there is still merit in that reluctance. But agreeing to stop supporting C++03 does not necessarily require code changes -- the absolute minimum would be to just stop running the CI for it, and an only slightly higher bar would be to change the build settings to refuse to compile. (Although some people are reluctant to go even that far -- if they're not actually changing the library to take advantage of C++11 then there's no technical reason why it wouldn't compile under C++03, so why block it? But there can be non-technical reasons why this may still be a good idea.) There's also some complexity in what "stopping supporting C++03" means, even if the maintainer does want to make code changes. Like it or not, there are differences between std:: and boost:: classes even where those largely intersect (e.g. threading, smart pointers, optional) and some have features or support that the other lacks. But even where functionality is sufficiently identical, swapping is an API-breaking change that will require edits to all downstream code -- probably trivial ones, and which the compiler will readily identify for you, but still there nonetheless. And there's a certain reluctance (rightly or wrongly) to impose that as well. There was an attempt a while ago to make this the end-user's responsibility to choose between the implementations via macros and policy templates, but it didn't really catch on (and I'm not convinced that it should). Given that C++ itself is largely backwards compatible (and despite the trash-talk I and others often give it for using the wrong defaults for everything as a result, this is a good thing); it's usually not hard to migrate an application code-base from C++03 to at least compiling without issue in C++14 or beyond, even if not taking advantage of new features or idioms. So it should not be a difficult barrier to say "hey, update to C++ab or this library will stop working". Applications and compilers already have to cope with a mixture of different standard levels intersecting.

Glen Fernandes

1:46 a.m.

On 6/05/2022 12:08, James E. King III wrote:

...

I for one would enjoy updating Boost.CI and the 16 Boost libraries that I maintain to stop running C++03 tests through CI

It's a little different here, because you maintain those libraries as part of the Community Maintenance Team. But other (full-fledged) authors and maintainers of Boost libraries are free to break C++03 compatibility for their libraries whenever they choose. They're technically free to do this even if this will break other Boost libraries. Ideally if they choose to do this, they communicate it to the maintainers of those other Boost libraries in advance of the next release, so they can plan accordingly. (i.e. If they want to retain C++03 support) Glen

John Maddock

8:10 a.m.

On 06/05/2022 02:33, Gavin Lambert via Boost wrote:

...

On 6/05/2022 12:08, James E. King III wrote:

...
I for one would enjoy updating Boost.CI and the 16 Boost libraries that I maintain to stop running C++03 tests through CI and stop claiming support for utterly ancient EOL compilers, as well as language levels.

As far as I was aware, it was already agreed several years back that maintainers of individual "leaf" libraries could decide to stop supporting pre-C++11 pretty much whenever they like (one or two versions of deprecation warning appreciated), and that new libraries did not need to be backwards compatible. +1, Nearly all my stuff has already used this leeway to move to C++11, OK so some of it hasn't transitioned to fully removing 03 support yet, but they will do very soon.

It's a little murkier for libraries that are depended on by other libraries; there you had to get consensus from the downstream library maintainers to stop supporting pre-C++11 too, either simultaneously or earlier.

I would personally argue that it makes sense now to move that forward to C++14 rather than C++11, but I don't think that's actually been formally discussed yet. Personally, there's little in C++14 that makes that move attractive for me. C++17 yes (for if constexpr). There may be a few libraries which could use the enhanced constexpr support in C++14, but otherwise I'm not sure how much practical difference this makes. On the other hand, C++14 is the current baseline for current compilers, so I have no objection to making this the current Boost baseline as well!

There's a certain amount of resistance to "forcing changes" on libraries that don't really get touched year-to-year, because changes require work and have potential to introduce bugs. While there are some benefits to rewriting older code to remove workarounds and use more modern patterns (making future maintainability easier), there is still merit in that reluctance. Right, plus someone has to actually do the work. For libraries that are basically dormant as far as development goes, I see little harm in leaving them as they are, even if they include atrophied C++03 workarounds. The workarounds will gradually wither anyway and get removed in time.

But agreeing to stop supporting C++03 does not necessarily require code changes -- the absolute minimum would be to just stop running the CI for it, and an only slightly higher bar would be to change the build settings to refuse to compile. (Although some people are reluctant to go even that far -- if they're not actually changing the library to take advantage of C++11 then there's no technical reason why it wouldn't compile under C++03, so why block it? But there can be non-technical reasons why this may still be a good idea.)

Agreed, but some older libraries could use upgrading for better C++1n support - someone mentioned initializer-list construction for bimap, I'm sure there are dozens of other small improvements that could be made. Many of them might even be pretty easy to do, we just need a TODO list ;) Best, John.

Niall Douglas

8:36 a.m.

On 06/05/2022 09:10, John Maddock via Boost wrote:

...

Personally, there's little in C++14 that makes that move attractive for me. C++17 yes (for if constexpr). There may be a few libraries which could use the enhanced constexpr support in C++14, but otherwise I'm not sure how much practical difference this makes. On the other hand, C++14 is the current baseline for current compilers, so I have no objection to making this the current Boost baseline as well!

C++ 14 has a *lot* of bugfixes over C++ 11. These won't matter to you until they do, and when they do, they are most frustrating. I note that when GCC and clang changed their default C++ standard they jumped from 03 to 14. They did not choose 11 at any point. I find that revealing. Looking around at other compilers, the only one which ever stopped at 11 as the default was hipcc. https://gist.github.com/ax3l/53db9fa8a4f4c21ecc5c4100c0d93c94 17 is also a fine default, which it is for GCC 11 onwards. Our work codebase was 17 right up until this week, when we expect to transition to 20 as the minimum. And I can then rip out lots of preprocessor macros, woohoo! Niall

James E. King III

1:57 p.m.

On Fri, May 6, 2022 at 4:36 AM Niall Douglas via Boost wrote:

...

On 06/05/2022 09:10, John Maddock via Boost wrote:

...
Personally, there's little in C++14 that makes that move attractive for me. C++17 yes (for if constexpr). There may be a few libraries which could use the enhanced constexpr support in C++14, but otherwise I'm not sure how much practical difference this makes. On the other hand, C++14 is the current baseline for current compilers, so I have no objection to making this the current Boost baseline as well!

C++ 14 has a *lot* of bugfixes over C++ 11.

These won't matter to you until they do, and when they do, they are most frustrating.

I note that when GCC and clang changed their default C++ standard they jumped from 03 to 14. They did not choose 11 at any point. I find that revealing.

Looking around at other compilers, the only one which ever stopped at 11 as the default was hipcc.

https://gist.github.com/ax3l/53db9fa8a4f4c21ecc5c4100c0d93c94

17 is also a fine default, which it is for GCC 11 onwards. Our work codebase was 17 right up until this week, when we expect to transition to 20 as the minimum. And I can then rip out lots of preprocessor macros, woohoo!

Niall

It would still be useful to have a plan going forward, where Boost as a whole follows a predictable pattern. It sounds like people would be more amenable to saying Boost will support the current and previous two language levels at a given release. In particular this means those will be the language levels that are tested for viability. I was originally recommending 3, but it's possible there is a consensus around 2. That means today, C++20, 17, 14 would be supported in whatever release adopted this strategy. Do we have an online tool for voting on proposals to assist? - Jim

Peter Dimov

8:38 a.m.

John Maddock wrote:

...

Personally, there's little in C++14 that makes that move attractive for me. C++17 yes (for if constexpr). There may be a few libraries which could use the enhanced constexpr support in C++14, but otherwise I'm not sure how much practical difference this makes.

Apart from usable constexpr, polymorphic lambdas are the other big thing.

Peter Dimov

8:41 a.m.

...

John Maddock wrote:

...
Personally, there's little in C++14 that makes that move attractive for me. C++17 yes (for if constexpr). There may be a few libraries which could use the enhanced constexpr support in C++14, but otherwise I'm not sure how much practical difference this makes.

Apart from usable constexpr, polymorphic lambdas are the other big thing.

Oh, deduced return types, too.

Glen Fernandes

11:24 a.m.

On Fri, May 6, 2022 at 4:42 AM Peter Dimov wrote:

...

...
John Maddock wrote:

...
Personally, there's little in C++14 that makes that move attractive for me. C++17 yes (for if constexpr). There may be a few libraries which could use the enhanced constexpr support in C++14, but otherwise I'm not sure how much practical difference this makes.

Apart from usable constexpr, polymorphic lambdas are the other big thing.

Oh, deduced return types, too.

Deduced return types and C++14 relaxed constexpr are of more importance to me than C++17 if-constexpr. To reach more users, 14 seems more appealing than 17. Although by now the big distributions ship with at least GCC8 which supports most of the C++17 core language but formally still only experimental support for the C++17 library... Glen

Vinnie Falco

1:24 p.m.

On Fri, May 6, 2022 at 4:25 AM Glen Fernandes via Boost wrote:

...

...

Apologies for asking again but what are we doing with Asio? Thanks

Glen Fernandes

1:31 p.m.

On Fri, May 6, 2022 at 9:24 AM Vinnie Falco wrote:

...

Apologies for asking again but what are we doing with Asio?

Deferring to what Chris wants to do with Asio, in light of dependent Boost library authors that no longer support C++03. Glen

Seth

1:58 p.m.

...

Apologies for asking again but what are we doing with Asio?

Nothing, I'd say. It's not like suddenly there will be a new review round that would reject existing libraries for implementing/maintaining arcane compiler support, I don't think. In short, it's about removing restrictions, not adding restrictions. Correct me if I'm wrong. Seth

Peter Dimov

2:47 p.m.

Vinnie Falco wrote:

...

On Fri, May 6, 2022 at 4:25 AM Glen Fernandes via Boost wrote:

...
...

Apologies for asking again but what are we doing with Asio?

Nothing.

Peter Dimov

3:03 p.m.

Glen Fernandes wrote:

...

On Fri, May 6, 2022 at 4:42 AM Peter Dimov wrote:

...
...
John Maddock wrote:

...
Personally, there's little in C++14 that makes that move attractive for me. C++17 yes (for if constexpr). There may be a few libraries which could use the enhanced constexpr support in C++14, but otherwise I'm not sure how much practical difference this

makes.

...
...
Apart from usable constexpr, polymorphic lambdas are the other big thing.

Oh, deduced return types, too.

Deduced return types and C++14 relaxed constexpr are of more importance to me than C++17 if-constexpr.

To reach more users, 14 seems more appealing than 17. Although by now the big distributions ship with at least GCC8 which supports most of the C++17 core language but formally still only experimental support for the C++17 library...

I'd say that the important standard conformance level is the compiler's default one, because that's what all the distro's packages use (and what `b2` uses if not given `cxxstd`, which is how Boost is being built today.)

...

From this standpoint, moving to C++14 is actually easier than moving to C++11, because the build procedure doesn't have to change (except for people still on GCC 5 or Clang 5 who will need to add cxxstd=14 unless we make this the default.)

Boris Kolpackov

9 May 9 May

12:34 p.m.

Peter Dimov via Boost writes:

...

I'd say that the important standard conformance level is the compiler's default one, because that's what all the distro's packages use (and what `b2` uses if not given `cxxstd`, which is how Boost is being built today.)

IMO, talking about targeting a C++ standard like C++11 or C++14 is not very useful since every major C++ compiler (GCC, Clang, MSVC) completes support for the next standard over multiple releases. As a result, while compilers may not have complete support, they often include a perfectly usable subset of the features. In this light, what we found more useful is to specify the minimum versions of the three major compilers that we are willing to support and any features that are available in all three are a fair game. I suppose specifying the standard (e.g., C++N), then mapping that to the versions of the major compilers that enable it by default, and then using them as minimum supported compiler versions would be another way to do it. But I think semantically the result is the same: you are only able to use a subset of C++N that is available in all these compiler versions. FWIW, in build2 we had good results with picking GCC 4.9, Clang 3.7, and MSVC 14u3 and getting a very usable subset of C++14 (including move capture and generic lambdas).

Soronel Haetir

25 Apr 25 Apr

7:45 p.m.

On 4/25/22, Hans Dembinski via Boost wrote:

...

Why anyone would prefer programming in C over C++ is a mystery to me, though, automatic memory management with std::unique_ptr and friends alone is such a boon. The C++ interface provided by Boost.Python and pybind11 is much easier to use than the original Python C API exactly for that reason.

One major reason for choosing C is that it provides a much wider compatibility window. That is, it is possible to link C-derived object files from a much wider set of tools into a single result binary. Even setting name mangling aside, C++ ABIs changed so frequently that it is generally unsafe to link C++ objects generated by different toolchains (often even the same toolchain with different options). C, on the other hand, has far fewer pitfalls in this regard. -- Soronel Haetir soronel.haetir@gmail.com

Gavin Lambert

11:56 p.m.

On 26/04/2022 07:45, Soronel Haetir wrote:

...

On 4/25/22, Hans Dembinski wrote:

...
Why anyone would prefer programming in C over C++ is a mystery to me, though, automatic memory management with std::unique_ptr and friends alone is such a boon. The C++ interface provided by Boost.Python and pybind11 is much easier to use than the original Python C API exactly for that reason.

One major reason for choosing C is that it provides a much wider compatibility window. That is, it is possible to link C-derived object files from a much wider set of tools into a single result binary. Even setting name mangling aside, C++ ABIs changed so frequently that it is generally unsafe to link C++ objects generated by different toolchains (often even the same toolchain with different options). C, on the other hand, has far fewer pitfalls in this regard.

Another reason that I have sometimes preferred C over C++ is for embedded firmware where (a) the compilers or standard libraries for C++ are sometimes more fragile [although since most of them have migrated to gcc/clang these days, that's usually less of an issue, though some still persist with a custom library] and (b) with C code you get pretty much exactly what you put in, whereas with C++ there can be a lot more hidden code and (sometimes critically) hidden memory allocations and exception paths, and there are often places where you need to absolutely guarantee that no memory allocation occurs. While it is certainly possible to use C++ in a fashion that guarantees no exceptions and memory allocations, and there are a lot of things that are nicer to write with stronger typing and templates, it's a lot easier to accidentally write unsafe C++ code than unsafe C code. (Conversely, code that does have dynamic memory allocation is typically safer to write in C++.)

Michael Caisse

22 Apr 22 Apr

1:48 a.m.

On 4/19/22 15:28, William Linkmeyer via Boost wrote:

...

+1

Although, I feel that there should be an *attempt* to make C++ libraries easy enough to use for anything.

(For example, say, use asio & beast for websites. I can dream, okay?)

WL

...
On Apr 19, 2022, at 10:42 AM, Vinnie Falco via Boost wrote:

It might be interesting to think about where C++ and Boost will be in

<snip>

Please don't top post. https://www.boost.org/community/policy.html#quoting Thanks! michael-with-his-mod-hat

Robert Ramey

11 May 11 May

10:27 p.m.

On 4/19/22 7:42 AM, Vinnie Falco via Boost wrote:

...

It might be interesting to think about where C++ and Boost will be in the next 20 years and in the next 50 years. There has been an explosion of research and development into new programming languages (Rust being the most visible example). C++ is hardly the most popular language (Python is, if the TIOBE index is to be believed). But C++ is an essential language because it occupies the unique position of being as close as possible to assembly language while remaining high level. The zero-cost abstractions, metaprogramming, and powerful compositional tools of C++ still have no competitors and they are unlikely to have them any time soon.

This doesn't necessarily mean that C++ is good for everything; there's an opportunity cost for all this. C++ code is generally more complex, harder to read, and harder to write than other code. Other languages are much better suited for certain tasks. No one should be implementing a content-driven website using Asio and Beast for example. But for the things that C++ is good at, it excels at them. A recent reddit post [1] provided a decent list::

* games * databases * high frequency trading * search (Google/Bing/DuckDuckGo) * web browsers (Chrome/Safari/Edge) * virtual reality headsets (Facebook) * distributed systems at big tech companies (Google/Microsoft/Facebook) * low level libraries (machine learning libraries like tensorflow and pytorch) * compilers, virtual machines, interpreters (JVM/gcc/LLVM) * robotics & hardware (ex: self driving cars, planes, missiles, space ships, etc)

My opinion is that wg21 (the C++ standards committee) has been growing increasingly out of touch with the needs of the larger C++ community. Not necessarily out of malice, but because the bureaucratic process of the committee does not align the incentives of its members with users. I predict that we will see the C++ standard library become increasingly irrelevant by not only failing to produce stable things that people want, but also by not even keeping up feature-wise with the library ecosystem of other languages. Where is Requests [2] for C++? Python has had this for over a decade.

In case you think I'm exaggerating, look at this comment from Reddit:

...a major vendor is getting ready to release a product that does not allow user applications to directly access TCP sockets so the only way to get any network access is to go through their standard library which only supports backdoored HTTPS.

This vendor of course is Apple, as can be seen in P1860R0 [4]. We should not expect that wg21 will be able to deliver an important feature such as networking in a form that will be usable or recognizable to non-committee members.

What does this mean for C++ and Boost? I believe there is a significant opportunity for Boost to step in and become the rational collection of actually useful libraries that the C++ standard library is not. We already have networking, some protocols, and JSON. We (the existing Boost authors and contributors) might consider looking to the list above of industries that use C++, and focus our efforts more towards providing libraries that enhance those industries. Perhaps by reaching out to leaders in those fields we might establish working relationships and build, say, the next Boost.Tensorflow or something like that. I don't know.

Oh, and add "cryptocurrency" to the list above. C++ is the language of blockchain, because performance matters.

What do you think?

...

My opinion is that wg21 (the C++ standards committee) has been growing increasingly out of touch with the needs of the larger C++ community. Not necessarily out of malice, but because the bureaucratic process of the committee does not align the incentives of its members with users.

Very well put.

...

I predict that we will see the C++ standard library become increasingly irrelevant by not only failing to produce stable things that people want,

Agreed It's time to refactor the IOS committee. a) redefine it's mission. Such a committee should address issues of the core language only. b) "standard" libraries may be provided by anyone. Venders, Open Source fanatics, high school students, etc. They may be given away, sold or what every. Since the language is already overladen with too many arcane features, the job for the IOS committee can be considered mostly done. The committee can shrink down to a manageable size. Getting your pet idea into the "standard library" to have other people code won't give you the excitement it once did. Oh well. Robert Ramey

...

Thanks

Vinnie

...

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

William Linkmeyer

12 May 12 May

12:59 a.m.

[Robert]

...

It's time to refactor the IOS committee.

a) redefine it's mission.

Such a committee should address issues of the core language only.

b) "standard" libraries may be provided by anyone. Venders, Open Source fanatics, high school students, etc. They may be given away, sold or what every.

Since the language is already overladen with too many arcane features, the job for the IOS committee can be considered mostly done. The committee can shrink down to a manageable size. Getting your pet idea into the "standard library" to have other people code won't give you the excitement it once did. Oh well.

With the exception of “paid” standard libraries, how is this not already the case? WL

...

On May 11, 2022, at 6:28 PM, Robert Ramey via Boost wrote:

It's time to refactor the IOS committee.

a) redefine it's mission.

Such a committee should address issues of the core language only.

b) "standard" libraries may be provided by anyone. Venders, Open Source fanatics, high school students, etc. They may be given away, sold or what every.

Since the language is already overladen with too many arcane features, the job for the IOS committee can be considered mostly done. The committee can shrink down to a manageable size. Getting your pet idea into the "standard library" to have other people code won't give you the excitement it once did. Oh well.

Robert Ramey

4:47 a.m.

On 5/11/22 5:59 PM, William Linkmeyer via Boost wrote:

...

[Robert]

...
It's time to refactor the IOS committee.

a) redefine it's mission.

Such a committee should address issues of the core language only.

b) "standard" libraries may be provided by anyone. Venders, Open Source fanatics, high school students, etc. They may be given away, sold or what every.

Since the language is already overladen with too many arcane features, the job for the IOS committee can be considered mostly done. The committee can shrink down to a manageable size. Getting your pet idea into the "standard library" to have other people code won't give you the excitement it once did. Oh well.

With the exception of “paid” standard libraries, how is this not already the case?

WL

In a large sense it already is almost. The whole step of writing 100's of pages of text after negotiating every word would disappear. Library providers would provide their own documentation. If the library is poorly made, poorly specified, doesn't work, what ever. The library becomes "online" when the author releases it. The he promotes it. It becomes standard iff it meets all the conditions for a "standard" library. Vendors compiler, and the set of standard libraries they want to include. Its their each decision. Robert Ramey

Andrey Semashev

10:04 a.m.

On 5/12/22 01:27, Robert Ramey via Boost wrote:

...

On 4/19/22 7:42 AM, Vinnie Falco via Boost wrote:

...
My opinion is that wg21 (the C++ standards committee) has been growing increasingly out of touch with the needs of the larger C++ community. Not necessarily out of malice, but because the bureaucratic process of the committee does not align the incentives of its members with users.

Very well put.

...
I predict that we will see the C++ standard library become increasingly irrelevant by not only failing to produce stable things that people want,

Agreed

It's time to refactor the IOS committee.

a) redefine it's mission.

Such a committee should address issues of the core language only.

b) "standard" libraries may be provided by anyone. Venders, Open Source fanatics, high school students, etc. They may be given away, sold or what every.

Since the language is already overladen with too many arcane features, the job for the IOS committee can be considered mostly done. The committee can shrink down to a manageable size. Getting your pet idea into the "standard library" to have other people code won't give you the excitement it once did. Oh well.

I assume you mean "ISO" committee, that is WG21? While I agree that the standard library defined by the C++ standard is insufficient for any more or less advanced programming (i.e. anything more complicated than simple "Hello World" style applications), and I personally consider Boost as the natural, almost mandatory extension of the standard library, oftentimes preferred over the latter, I disagree that the work on the standard library is done, or that it isn't needed. It's actually the opposite. There is a number of fundamental library components that are required for the core language (std::type_info, exceptions and their interactions with core language like dynamic_cast, std::initializer_list, etc.). There is a number of utility tools which are used ubiquitously (std::string(_view), containers, std::pair, std::tuple, threads and synchronization, type traits). There is support for basic IO - even if it isn't suitable for anything sophisticated like mapped files or sockets, having no IO at all would be clearly worse. There is a considerable portion of the standard library that implements compatibility with C. And so on. All these things form a baseline on which any C++ program can rely regardless of the language implementation. It is important to have that baseline as it sets the lowest bar of what can be implemented in pure C++ with no external dependencies, and without many of the tools I listed no useful program is possible. The fact that we are forced to use Boost or Qt or GTK or whatever other framework of libraries to implement any real world applications indicates that this bar is too low currently. That said, I do agree that the current approach to the standard library evolution is not scalable. I think, the standard library needs to become more modular, ironically, more similar to Boost (or where it aims to be). There needs to be a separate module for networking, for mapped IO, for parsing a-la Boost.Spirit, for JSON, XML and other widespread data formats, for GUI (non necessarily buttons and menus, but at least the ability to draw something on canvas), video and audio, for SIMD, for databases, for more containers and many many more. I think the committee is already moving in this direction, although they are still trying to cram everything in a single specification and market it under a single C++NN label. I think, this needs to change at some point so that every module is able to evolve at its own pace and in a separate specification that is addendum to the main C++ specification that describes core language and core standard library components. The main difference of this modular approach from the status quo is that there would be a formal specification for each module that every implementor would have to follow, and all users could rely on. Furthermore, there are multiple C++ language implementors, so there would be multiple implementations of each of these modules, arguably more optimized for the supported target platforms. Basically, you would have a portion of Boost or Qt shipped with every C++ compiler, with no extra dependencies. This is better in terms of accessibility, implementation quality and likely licensing. Because competition is always good.

928

Age (days ago)

952

Last active (days ago)

List overview

Download

50 comments

22 participants

participants (22)

Andrey Semashev
Boris Kolpackov
Gavin Lambert
Glen Fernandes
Hans Dembinski
James E. King III
John Maddock
Kostas Savvidis
Marshall Clow
Mateusz Loskot
Michael Caisse
Niall Douglas
Oliver Kowalke
Peter Dimov
Richard
Robert Ramey
Seth
Soronel Haetir
Stefan Seefeld
Timothy Keitt
Vinnie Falco
William Linkmeyer