Hacker News Reader

Comment by xvilka | Hacker News Reader

Should drop anything below C++14. Everyone who is not happy could always stay on older versions.

Why not go for C++17 already? C++14 seems pretty arbitrary, AFAIK C++17 is already supported by GCC, clang and MSVC fully [0]. It's also now the default dialect in a few compilers including GCC. Meanwhile C++20 isn't really well supported at all in the moment [1] so it makes sense waiting more for it, even though features such as Concepts and Modules should simplify library code a lot and make some tasks much more trivial.

[0]: https://en.cppreference.com/w/cpp/compiler_support/17

[1]: https://en.cppreference.com/w/cpp/compiler_support/20

The argument I can see is that 14 is the minimum feature set that every engineer knows how to use, and before 14 you are missing some of the "core" features of the language that are widely used today. By contrast, some things in 17 are still foreign to some engineers, although there are no real "breaking" changes from 14 to 17 (in terms of the model of how to think about the language). 20 and 23 are a bit of a mess in terms of support.

6 years is more than enough time to get ready for the update. If you can’t work out how to use c++ 17 then that isn’t the problem of library devs.

Last time I read about it, PlayStation SDK was on C++14, and they aren't the only platform in such state.

Unless Sony is financially contributing, I don’t see why a 3rd party would care that the PlayStation sdk is running legacy software.

Right, same can be said regarding current state of ISO support on free beer compilers, now limping behind VC++.

So taken to extreme, some Boost libraries might become VC++ only, for authors that decide to go fully on ISO C++ 20 and 23.

What do you mean free beer compilers are limping behind VC++? The situation (as always) seems exactly the contrary. [0]

[0]: https://en.cppreference.com/w/cpp/compiler_support/23

They would do better to finalise their ongoing issues with C++20 features support, instead of spending valuable resources on C++23.

See their C++20 support versus VC++.

As you can see by those tables, there are other compilers in the world, and those tables don't even include embedded platforms.

I don't think embedded platform code uses Boost though, right?

Who knows, there are many definitions of embedded.

Modern embedded platforms like ESP stuff can run pretty much a full c++20 standard library and thus most of boost without issues

I’m living in a world that has to support a product which has many parts in C++ on Solaris, HP-UX, and OS/400 (in addition to Linux, AIX, and Windows). We can’t drop support yet for the AIX release that only support up to C++ 11 although they have a newer clang based compiler. HP-UX and Solaris native compilers only go to C++14. Those platforms have at least 5 years of enterprise support yet, but no new chipsets mean no extended compiler development. And up-to-date gcc doesn’t build there.

And then IBM’s OS/400 ILEC++ support isn’t even up to C++11.

It is hard to live in Enterprise software land where you support everything for a lot of years, but end up stuck on older third party libraries when they move to new standards to keep parity across your product line’s feature set.

In a similar vein, here it is mostly .NET Framework, and now we finally moved into Java 11.

With .NET 8 and Java 21 around the corner,....

It feels like living the Python 2 / 3 transition.

The wonderfull enterprise land.

This reminds me of my time at Bloomberg. The C++ support from IBM and Oracle/Sun wasn’t nearly up to date, and without a large customer willing to foot the bill to improve the toolchains IBM and Oracle/Sun weren’t going to do the work.

There was a Linux migration project to move the company to Linux. I haven’t heard anything from people inside, but I’m willing to bet that there are still some stragglers that haven’t moved yet.

Reply on news.ycombinator.com