C++17 Is Complete, Work On C++20 Is Getting Underway

[ssokolow]

It's still irritating. Rust was the first language that made me feel comfortable working in something that compiles to native code and I do want to shout it from the rooftops, but I have the tact and perspective to know why that's a bad idea.

I get the impression all of these people have never actually coded anything more significant than a lab project in some high-school programming course. (Even with the projects where I do plan to rewrite from Python to Rust for reasonable gains in reduced maintenance burden and even for the ones which are tiny little utilities, it's not as if I'm going to find time immediately and the new version won't match the old one overnight. The fact that you can link Rust modules into C programs isn't magic pixie dust.)

[liam]

Sure it is but I understand the emotional flamewars to some extend. There are a handful of people who got proficient to some degree and can show years of experience. They manage to do really great things with their tools.
Then some newcomer hipster comes (often without in-depth knowledge of anything with the need to distinguish himself) and tells them it is all unnecessary deprecated and bad ...

You think graydon hoare is a hipster? I suppose chris lattner is just a damn hippy!

[Kemosabe]

You think graydon hoare is a hipster? I suppose chris lattner is just a damn hippy!

So you blame them both to visit (phoronix) forum flaming abt programming languages? You sir, are a troll!

[coder]

As a practicing C++ programmer, I really fear they're going to keep adding stuff until it becomes unlearnable and unimplementable. C++ already has a learning curve years long, and that's a big impediment to hiring developers.

IMO, they should just fix stuff that's broken (i.e. not fully usable as intended or as people are trying to use it). Std libraries should focus on portability, abstract data types, and fundamental algorithms.

And 2D graphics has a scope far too large, and it's difficult to do in a truly one-size-fits all fashion. Another thing that makes it a poor candidate for ISO standardization is the likelihood that you get everything right in the standard. They'll have to do lots of bug-fixing and cleanup. Industry consortia like Kronos are much better vehicles, for things of this sort.

[Kemosabe]

As a practicing C++ programmer, I really fear they're going to keep adding stuff until it becomes unlearnable and unimplementable. C++ already has a learning curve years long, and that's a big impediment to hiring developers.

IMO, they should just fix stuff that's broken (i.e. not fully usable as intended or as people are trying to use it). Std libraries should focus on portability, abstract data types, and fundamental algorithms.

And 2D graphics has a scope far too large, and it's difficult to do in a truly one-size-fits all fashion. Another thing that makes it a poor candidate for ISO standardization is the likelihood that you get everything right in the standard. They'll have to do lots of bug-fixing and cleanup. Industry consortia like Kronos are much better vehicles, for things of this sort.

The changes are indeed an improvement and people who are actually bother looking at the changelog and know C++ will appreciate them.

Previously:

namespace Microsoft {
namespace Windows {
namespace 10 {
}
}
}

Now:

namespace Microsoft::Windows::10 {
}

Previously:

for (char byte : binaryfile) {
// Oh look at that, I read the binary bytewise and it's a char type for some historic reasons. Sooo "hard to learn and non human understandable!"
}

Now:

for (std::byte byte : binaryfile) {
// yeah I read the binary bytewise and there is a type for it and not an ancient integral C type.
}

And besides that 2D graphics will be a std library. It will not change the syntax or the features of C++ it is just bundled with glibc++ which makes it 100% platform independent and compatible. Nobody needs to know all the libraries out there. Same for filesystem access and multithreading.

You don't want a modern language coming with Filesystem, Multithreading and GUI support? Java has it all and nobody complains about that... Cairo for 2D GUI is the perfect candidate since everybody is using it for good reason. The Kronos group however is completely different goals and purpose! ;-)

[coder]

The changes are indeed an improvement and people who are actually bother looking at the changelog and know C++ will appreciate them.

It's not about agreeing whether feature XYZ is an improvement, it's about whether it offers enough benefit to introduce incompatibilities in code. I have already run into a library that I can't use on a particular platform, because its compiler doesn't yet support some of the C++17 feature the author decided to use.

We can both agree on ways that a feature could be improved upon, and still disagree on whether it should be added to the language. Sorry, but I don't find any of the examples you gave to be sufficiently compelling.

As for std::byte, there's already uint8_t, and I fail to see the value in pretending that it can't be treated as a signed or unsigned integer. I will agree that having the same type for characters and 8-bit integers is sometimes an issue.

And besides that 2D graphics will be a std library. It will not change the syntax or the features of C++ it is just bundled with glibc++ which makes it 100% platform independent and compatible. Nobody needs to know all the libraries out there. Same for filesystem access and multithreading.

It's not the same. I have a deep history in graphics and video, and I can tell you there's not a one-size-fits-all graphics library. In that regard, it's different than threading and filesystems, where a standard API (which overlays stable, legacy APIs from Posix, Windows, etc.) handles all that 99% of C++ developers will ever need, in those areas. Graphics is more specialized for what you're trying to do.

Now, I'm not saying that standard graphics libraries are bad, particularly when they can expose some level of hardware acceleration. I just think an ISO standard is the wrong vehicle.

And if you like Cairo, great - why not keep using Cairo? Why bloat up the standard with it?

There are two major downsides to putting it in the C++ standard. First, it'll inevitably have shortcomings and bugs, which will push library developers to adopt C++23 features, restricting the usability of their libraries on platforms that aren't at the bleeding edge. Second, it further raises the bar for any platform that wants to provide a standards-conformant C++ implementation. I already have to maintain support for one C++ code base on a DSP without a fully-C++11 conformant compiler, even though that's not its primary platform. That's a rather atypical example, but I think it illustrates my point.

The C++ standards committee should not be trying to figure out how much more stuff they can cram into the standard. They should be figuring out what are the big pain points for real-world users of C++ that can only be effectively addressed by updating the standard. BTW, I think the restrict keyword is one such example. I would also appreciate keeping C++ as a superset of C.

[cl333r]

Great, now C++ is worth a book 900 pages instead of 700.

[mmstick]

standard is to break only code which deserves to be broken. not to expect constant rewrites from your alphatesters

This is complete nonsense. The latest Rust nightly from today still compiles code written two years ago for the 1.0 compiler, and breaking changes to the Rust API are disallowed completely. Features may be added to the language and standard library, but existing features may not be modified in a way that breaks any existing code. That would go against SemVer and the Rust language designers wishes.

[hansg]

Keep patching and patching the beast instead of using a sane language such as Rust.

I was ridiculed when I complained that the Rusts-evangelists should really learn to _shut up_, and not pollute every topic with mentions of their irrelevant toy language (*). Some other language has a new version? "USE RUST BLABLABLA!" Bug found in something written in another language? "USE RUST BLABLABLA!" I don't actually hate Rust, I find it kind of interesting, but boy are the people involved with it tiresome...

(*) No stable formal standard, no multiple independent implementations, and no industry track record.

[hansg]

It's not about agreeing whether feature XYZ is an improvement, it's about whether it offers enough benefit to introduce incompatibilities in code. I have already run into a library that I can't use on a particular platform, because its compiler doesn't yet support some of the C++17 feature the author decided to use.

You either fix a language so it never changes again, and become irrelevant, or try to move with the times. So far, I've found each successive iteration of C++ to be an improvement, making my life as a programmer easier. But yes - that means you will from time to time find that your chosen compiler does not support a new feature already in use by others.

As for std::byte, there's already uint8_t, and I fail to see the value in pretending that it can't be treated as a signed or unsigned integer. I will agree that having the same type for characters and 8-bit integers is sometimes an issue.

For what it's worth, I agree. It's nice(?) that we now have a binary type that does not support certain math operations - but you know what, you can't use it to implement something like compress() because that _will_ need those math operations internally. That sort of defeats the point, doesn't it? uint8_t would have been more than enough.

It's not the same. I have a deep history in graphics and video, and I can tell you there's not a one-size-fits-all graphics library. In that regard, it's different than threading and filesystems, where a standard API (which overlays stable, legacy APIs from Posix, Windows, etc.) handles all that 99% of C++ developers will ever need, in those areas. Graphics is more specialized for what you're trying to do.

For the vast majority of the people, being able to do some simple drawing would be a great addition to the standard. And it won't stop you from doing specialized stuff with your own libraries if you need it. The elephant in the room isn't 2D graphics anyway; it's windowing systems and event processing. If the standard has that, you could write a full desktop application in standard C++ without needing any kind of system-specific code, but it will be a very tough nut to crack. Both because operating systems are so different, and because moving the event loop into the library is a very, very significant change.

Ah wait, there is actually another elephant in the room. Do I understand correctly that all text processing was removed from Cairo in the 2d graphics proposal? That would be completely pointless then... I know text rendering in Cairo is somewhat limited, and that most people will use it in combination with Pango, but if the standard does not offer any way to render some text it might as well not bother at all.

There are two major downsides to putting it in the C++ standard. First, it'll inevitably have shortcomings and bugs, which will push library developers to adopt C++23 features, restricting the usability of their libraries on platforms that aren't at the bleeding edge. Second, it further raises the bar for any platform that wants to provide a standards-conformant C++ implementation. I already have to maintain support for one C++ code base on a DSP without a fully-C++11 conformant compiler, even though that's not its primary platform. That's a rather atypical example, but I think it illustrates my point.

One way to approach this would be for the standards people to not only specify an interface in the standard, but also make available a reference implementation that compiler builders can freely use in their compilers (and taylor as they see fit). This would make a high quality implementation available to all, and significantly reduce the load on compiler builders. Of course the reference implementation would not be mandatory; any implementation that meets the interface would still be acceptable.

The C++ standards committee should not be trying to figure out how much more stuff they can cram into the standard. They should be figuring out what are the big pain points for real-world users of C++ that can only be effectively addressed by updating the standard. BTW, I think the restrict keyword is one such example. I would also appreciate keeping C++ as a superset of C.

Restrict is a fine example of a keyword that will make an already bad situation worse because it is both easy to use incorrectly, and difficult to detect such incorrect uses (so the standard will happily drop you into undefined behaviour land). If anything, I would prefer that the standard would focus more on removing cases of undefined behaviour where possible, and raising the bar on mandatory error reporting for cases it cannot outright eliminate, but that compilers can be expected to detect anyway. Moreover, I would like a rule to state that undefined behaviour, _if detected by the compiler_, must actually be an error condition, rather than an excuse to let the optimizer go wild.

I'm not saying that pointers should be checked or anything silly like that, but if a compiler decides that it can completely eliminate a block of non-trivial code because an earlier pointer dereference "proves" the block will not be executed anyway, it should at least issue a diagnostic and not just quietly eliminate that block.

Oh, and let's not kid ourselves: compatibility between C and C++ is already pretty damn bad for anything that is not a trivial piece of code. As someone who recently ported a fairly major piece of code from C to C++, I can tell you incompatibility runs far deeper than you currently imagine. At this point, C++ would be better off dropping C compatibility completely, except for those bits that allow it to interoperate with a library written in C. At least that would open the door towards fixing or deprecating the worst parts of the C standard library, and remove at least some warts on the language.