C++ Club - Kona, WG21 November mailing, contracts, C++ popularity and safety

Episode Date: December 28, 2022

With Bjarne Stroustrup, Gianluca Delfino, Vladimír Arnošt and other colleagues.Video: https://youtu.be/2mDSBN7jjLENotes: https://cppclub.uk/meetings/2022/157/

Welcome to C++ Club. This is meeting 157 and today is the 8th of December 2022. Good news everyone! C++ overtakes Java in Teobie Language Popularity Index. Actually that doesn't mean anything, as you probably know. But yeah, a good headline, I suppose. There is a Reddit discussion about it. Actually, the article shows the ranking. First place, Python. Second, C. Third, C++. Fourth, Java. And then C Sharp, Visual Basic.

And so on. So C is terribly higher than C++. Well, if you believe this rating. Well, if you believe this, Reiter. Well, there's this language C slash C++ that people always talk about, which I somehow never have encountered. Anyway, look to see how GOP is actually calculated. And it's measuring noise. I think all of the complaints and stuff about C++ has been good to us in terms of T.O.B.

People complain a lot, the language goes up. There's no such thing as bad advertisement, I guess. There's no such thing as bad advertisement, I guess. There's no such thing as bad advertising, you're right. So, Stefan T. Lavewey of Microsoft commented on Reddit. He said, quote, TLB is junk information, regardless of whether it seems to be good or bad news for C++. There's nothing useful about it, nothing that will help people make better decisions. I believe that posts about it should consistently be removed. That is, C++ is becoming more popular. It's actually as annoying as C++ is becoming less popular. Oh my god, whatever shall

we do when the measure is distorted beyond any connection to reality? Unfortunately, not everybody realizes that. So often I hear somebody say that the rankings mean something. I mean, all the surveys say C++ is more widely used than C. And every one of these measurements based on web information says C is used significantly more than C++, or at least a little bit. It's like the college rankings. It measures something and you're not quite sure what. Maybe some query results are parsed wrong and the plus pluses drop on some of the answers. I had that theory and I tried to verify it and failed. At least it didn't seem obvious. So other notable replies in the thread were, Rust will overtake C++ versus, no it won't.

Another quote was, C++ got much nicer with C++ 17 and 20 so obviously those who were disgusted by pre-C++ 17 or even pre-C++ 11 are coming back to C++. Another quote only a fool starts a new embedded project using C unless it's for a rare niche platform that doesn't have a working C++ environment. Unfortunately, there are still many fools around." And in reply to that, another quote, "...only a fool starts a new embedded project in C++ unless it's for a rare niche platform that doesn't have a working Rust hardware abstraction layer." So there you go. Rust is getting mentioned everywhere. Onto more interesting topics.

Kono Trip Reports are coming in. This one's by Herb Sutter. He says it's the first hybrid in-person remote conference and it went smoothly thanks to Jan Smarter and Dietmar Kuhl leading a group of volunteers who trialed this in September. So it looks like the hybrid meeting wasn't as bad as feared. It wasn't a total disaster but as somebody who attended it uh remotely i can't say i was very pleased the time difference was bad the fact that i wasn't away from my normal was bad and the larger groups like the evolution group it's hard to keep track of who was speaking. And when you want to talk about sort of more general philosophical, directional things, it's not anywhere near as effective as it is in a small group focused on specific issues.

So for issue processing, it worked rather nicely. What I'm mostly interested in, I'm not too pleased, are in-person scouts of times. It's always the size and the topic matters immensely, and people sometimes forget that. Well, hopefully more people will be there in person next time and also the experience with remote attendance will help make it smoother in the future, maybe. Herb says about extending the lifetime of temporaries for the range4 loop looks like we are getting it fixed in C++23. But this lifetime will not be extended anywhere else, so it'll be another special case according

to the wording proposed in a separate paper. Is this a good thing for teaching i guess you know it's easier not to have to explain this at the very beginning when maybe you want to introduce the for loop before range loop as a concept and you don't want to explain the the lifetime extension rule but then you're going to have to eventually explain another special case instead of just the reasoning behind the original special case. Jan, what do you think about this? You have extensive experience here. Did you vote for this? I don't remember. Let's say it this way. What you just said was that several people felt that you shouldn't have more special cases, but couldn't find a general case that would actually solve this, except by having

temporaries live to the end of the scope, always. That would have solved the problem. And the reason they don't is that that meant that there was a lot of extra pressure on the memory and the registers, and that was why it was moved to the scope of the statement back in, I think, 1882 or 1883. No, it think, 82 or 83. No, it must have been 83. And there were some complaints that even this extension

creates more memory pressure. That is, it saves a lot of beginners from a lot of problems. And for that reason, people was in favor of it strongly and a claim that the people that has expert problems I experts and have problems with the special case here well I suppose it will help improve safety of the construct without... For some definition of safety. It'll mean that certain users will not get bugs that they get now. Nico, your service was very, very vocal on people getting bitten by temporaries

and not understanding the lifetime of temporaries. And that was why the proposal was made, and that was why the proposal succeeded. There will still be people that get bitten by the lifetime of temporaries, but not in this particular case. I do wonder if after they fix this very ad hoc case, if you probably will be able still to get into the same problem if you manually write the code

that usually the compiler writes for you for the four range loop, which is auto, ref and then the the argument the argument is that it takes care of the common case and I don't think anybody claimed that it solved all the cases and the discussion was whether that mattered the people that claimed that you shouldn't have an extra case was voted down massively it It's a difficult thing to... I mean, I am of two minds of this, because in one hand, I'm happy that maybe newcomers will have less problems, but then my brain is already having a hard time coping with all the special cases already.

That's my problem, I guess. There was another paper that I briefly glanced at about a more common case of initialization and temporaries. There was a keyword used, const init or something. Ah, the one that introduces extra keywords in front of the... Yeah, yeah, yeah. There was extra stuff that looks even more confusing. I don't know. Yeah, I've seen it in the mailing list.

Right. So in Kona, it looks like contract roadmap was adopted, which makes it slightly more possible to have contracts in C++ 26, I think. Also, standard execution is coming in C++ 26. I think when you take off contrast, you should look for a paper by Gabi. Gabby, that's a bit hard to read, but basically it's trying to avoid having UB in contract predicates. If you have UB in a contract predicates, you could have a contract test check removed completely by the optimizer.

Ah, right. That is the problem Gabby is trying to deal with. I don't think people realized that that means that you can put a contract in, put a predicate in that's a little bit elaborate. The compiler decides that there's UB in what you wrote. Therefore, it doesn't have to do your contract check. And that is the problem that GAB is trying to address. Also, there was a paper I submitted,

which is about the fact that you can't use contracts in any library that is meant to be used in a program that may not terminate unconditionally. Yeah, I saw a paper that was a set of questions regarding Gabi's paper. Gabi is answering that for the next mailing and the point about UB that I just made will be more prominent this time. I think Debbie was too indirect and subtle and detailed and assumed people understood the problem. Yeah, my impression after reading that questions paper was that the questions were mostly about avoiding side effects. I don't think that's the main issue. Personally, I don about avoiding side effects. I don't think that's the main issue.

Personally, I don't mind side effects. But I do mind UB and eliminating by time travel optimizations, eliminating contract checks. If you do include side effects in the contract, does it mean that usually you would keep the contract check on by default in the release? Is there like a way to disable it? What's the design? I don't think that's specific to this design, but there are people who keep contract checks on in the ship code. And I would at least like to leave some contracts in some programs. There are people who think that contract checks

should never be shipped. And I think are not quite realistic. They have not seen industrial uses of contract systems. It's a theoretical decision. And you can afford it in many locations, places where the vast majority of coders can afford some contract cheaters. But as I said, I think the issue is UB and termination, not side effects. If you don't like side effects, don't write them. That's a perfectly logical position. If you don't like UB and don't write it, it is not a viable statement. In C++ 26 we're also getting standard execution, it looks like.

And also hash embed is coming to C++ 26. The C++ ecosystem international standard was accepted. Yes, so we have tool interoperability on the horizon, hopefully. And the next meeting will be in Issaquah in February 2023. Another trip report by Corentin Jabot. He wrote about certain proposals. His own views enumerate and I think it's coming in to C++ 23 with some caveats. Basically the issue seems to be what kind of type you would get by enumerating a view, because the idea is that it's a view that yields an index and an element for each element of a range. Which should be convenient, but there was a question whether it was a tuple or something akin to a pair or something completely

custom. And I think it will be a tuple. He also has a paragraph on C++ safety and its future, mentioned concerns that C++ is being discouraged for new projects by several branches of the US government. He says there is no solution but there are a plethora of targeted solutions to fix some of the common vulnerability vectors. And one of those, he says, is sanitizers. And by employing hardware support for certain teachers on new hardware platforms like ARM chips and recently Intel as well, it's possible to make sanitizers much faster. Gabby and I have a paper discussing an approach that gives complete type and resource safety. And that's been tested out in Microsoft's static analyzer and the core guidelines. You don't have to take the overhead of sanitizers. They will help until we get something better, but we can do

better than that. Read Gabby and my paper. There's more coming in that direction. Is this something new? Can we do some googling on this? I'm extremely interested. I think it was shipped. Let me just look.

Was it in this latest mailing? I think so. Right, so this is the mailing. Yes, it's P2687 by me and Gabby. 26? Hang on. Yeah, it's at the bottom. It points out that there's many different kinds of safety that different people like. Have to be able to support a variety, not just safety is not just one thing.

And we point out that one of the problems you have to deal with is how do you give safety guarantees in a environment where not all code is written to the same standard? I think those are the two key problems. And then, of course, we have to maintain the right decent code, and you can get decent performing code and all this other good stuff. If you slow down or complicate C++ too much, or if you change the semantics of various things, people will just use the old stuff. We actually have to match what we can do now for people

to keep using C++. If you get a slow version, Java, which is safe C++, it was advertised like that. Just get something that isn't C++, and people will need something at the lower level that doesn't provide the guarantees so they can run fast. This is not an easy problem. So this is R0. It was done to be in this mailing and R1 will have many more terms.

Right. The paper C++ is the next C++ has a new revision in this mailing and it specifically addresses the differences between your paper and that one. I haven't read it yet. So this is the paper revision one. This is about introducing subsets of C++ on the module basis using attributes that provide certain static checking. And in the frequently asked questions one of them is, do you fear that this could create a subset of C++ that could split the user community and cause acrimony? This is the quote from your paper. He says, does this paper create a subset? Yes. Like it or not, C++ already has a couple of subsets, some positive, some quasi. Freestanding

is a subset for low-level programming. This proposal primarily focuses on high-level programming, but there is nothing preventing the creation of static analysis inclusion's freestanding attribute. The C++ value categories have, to some degree, fractured the community into a clergy class that thoroughly understands its intricacies and the other class that gleefully uses it does this paper split the user community yes and no it splits code into safer versus less safe high level versus low level however this is performed at the module level allowing the same programmer to decide what falls on either side of the fence. Yeah, so it's evident that safer modules using less safe modules would be a problem.

And unsafe code using safe code is also a problem, because the safe code assumes certain guarantees. It's a difficult question. That's a thing that I've discussed in some detail with Gabby and Mike. Yes. And I feel it's missed. Both the general discussion sort of out on the web is safe versus non-safe and safe is in my opinion not one thing and it's also absolute all the code being safe or none but the point is that all of the safe languages use unsafe languages in their implementation, what they deem unsafe,

and they call unsafe modules like the operating system as part of their implementation. So it's not that easy to get away from the problems and we have to think pretty hard about how to do that best. There's a lot of gut reaction there which I think we have to worry about because it takes thought. Seems like it's also a marketing problem like we have somehow a bad reputation whereas not all the good reputation of some other languages is warranted. A lot of the other languages are marketing themselves by saying C++ is bad and we're not C++. That's their main marketing trick. And that has been happening throughout history.

So I'm not surprised. Another section of his, Jared Waterloo's paper, talks about the differences between his paper and your design alternatives for type and resource safety. He says it's different audiences and different scopes and different solutions. Quite a lot of text. Yeah. Some more from Kona.

This paper, A plan for better template metaprogramming facilities in C++ 26. Carentan mentions it in his report. And he's disappointed at the reception for this. This paragraph in his report is indexing a pack. So the idea was that variadic argument pack would be indexable, like an array or a container, and that would simplify metaprogramming. There wasn't a consensus on this, but at least there was an encouragement for more work in this direction. Some people said that reflection will solve this problem,

but he says, don't get me wrong, I fully support reflection, although I will say that we have not made progress in the past few years, but using reflection to index a pack is like trying to kill a fly with a nuclear warhead. There is a quote by Andrei Alexandrescu who says, given a C++ parameter pack P, how do you get the nth type in it. And then there is a pretty long line of code which does it. And then Andrei says, quote, C++ variadic templates seem to be the result of a gang war. One faction wanted to make them as complicated as possible. Another wanted to give variadics as little power as possible.

Those gangs cancelled each other out, and the design was done by a group of tech macro experts. Some people like very fancy quotes. They don't always relate exactly to reality. I tend to dismiss any quote that mentions atomics, except if it actually is discussing shear power plants and things like that. But just throwing them in for effect is, I bit, yes. This is Corentin's example of hash embed. So you say const unsigned char foo array equals open brace and then you say hash embed foo.bin closed brace and that will give you an array of

unsigned characters read from that file at build time. Another interesting proposal that seems to have been accepted is using underscore as the name of a variable whose name really doesn't matter. I've seen that in other languages like Scala and I guess that should be useful. Just ignore any underscore named variables in the current scope. And another accepted proposal for C++23 is static operator subscript. So this is going to be a class level subscript operator. The next is a lighter topic. Mark Rusinovich, the author of well-known Windows Sysinternals tools, he's also a CTO of Azure. He tweeted, Speaking of languages, it's time to halt starting any new projects in C slash C++

and use Rust for those scenarios where a non-gabbage-collected language is required. For the sake of security and reliability, the industry should declare those languages as deprecated. To that I laugh in C slash C++. I copied the tweet into the show notes in case he decides to delete it later, or if Space Karen finally kills Twitter. There are lots of discussions on Reddit about it and some quotes. The AAA games industry would beg to differ. No one seems to take it seriously except those who need to write articles with catchy titles. Like this one in Ziff

Davis Net magazine. Programming languages. It's time to stop using C and C++ for new projects, says Microsoft as US CTO. This is one of the people we can thank for the higher rating of C++ on CLB. That is true. The Register accidentally invokes the Betteridges law of headlines with their article titled Is it time to retire C and C++ for Rust in new programs? And if you don't know, Betteridge's law of headlines says that

if a headline is a question, the answer is usually no. I didn't know that one. It's an unofficial law, and Mr. Betteridge is a British journalist who's on Twitter, and people like to mention him when they see a headline like that. This article also caused probably a spike in C++ searches for T.O.B.

The pool of talented C++ developers is running dry. Yeah, it may be true. It's partly because all the good ones are already employed. And it seems that the number of C++ programmers are still going up significantly. So either the pool of good programmers are not growing, or the new ones aren't quite as good as the old ones, or maybe they're not quite as experienced yet because they haven't got enough years on their backs. This is very difficult to understand. We would all like to see more and better C++ programmers.

At least we've got more. In the Reddit thread for this article, someone said, I know I retired recently, but I didn't expect it to have such an impact. But seriously, companies having trouble attracting people might want to look at what they are offering. Perhaps cheap and talented C++ developers are hard to find? Definitely. And the article starts with this quote.

Software companies have a problem. There is not enough candidates that can code C++. This was the consensus in a webinar from ProfitView, a crypto trading tools developer, on high-frequency trading using C++. A cryptocurrency trading firm can't find good developers. The quote goes, where are all the C++ programmers? People are seemingly scared away from the language by a terrible stigma.

The notion that it is a legacy program with big names in tech such as Microsoft Azure CEO Mark Rusinovich calling people to deprecate C++ for the sake of security and reliability in favor of Rust, this is hardly surprising. The surveys I have seen says that in over the last five years, the C++ developer community grew by two million. That's how much in a month and how many developers, full-time developers, does other languages have. A lot of this stuff is just hot air. True. Provides for the article writers, though.

If I was a conspiracy theorist, I would make up that this was the C++ whatever, publishing these things to improve their TOB ratings. The C++ lobby.

Yeah, I was thinking of something more like the Templars, and we have to have proper conspiracy theories here. The Illuminati. That was it. The ending of this article is somewhat encouraging. Quote, The reality is that there are plenty of C++ jobs available in finance, and that compared to other languages, there are comparatively

few people to fill them. The language may be hard, but it's also worth it. Yeah, I mean, there's a reason why they are all searching for C++ programmers. The use of C++ is growing. So there might be slightly more to this article about this particular author, because there is a very very long comment on Reddit about interviewing practices at the company the article author works for. And oh boy, you can read it for yourself, but I think the problem might be just there.

Another article from the same website is titled C++ is the new Python. I don't know what that means. I hope not. C++ is not aimed at everybody the way Python is. I would like lots and lots of

good developers and good engineers using C++. But I really would fear if just about everybody tried to write everything in C++. That's not what it's for. The title is weird, but the article says that C++ is making a comeback. I didn't know it was gone. I mean, it's declared dead every year. It has been for the last 40. And the other article is about you, Bjarne, actually. It's a bit outdated.

The title goes The World's Top C++ Programmer and What He Does at Morgan Stanley. So, it's outdated. And I'm sorry, but calling Bjarne Stolstrup the top C++

programmer is like calling Tim Berners-Lee the top web designer. Right. So let's come back a little to the mailing. And I wanted to look at some more papers. This paper, Beta Stereotopal Indexing. It proposes an interesting thing, basically. It's sort of a literal with the IC suffix, which would enable you to index tuple members. Instead of using stdget with the template parameter for the index of the tuple, you would use the subscript operator, and the index would be a number, and then immediately after that lowercase ic.

I think we've seen this trick in one of the tweets, and I think I sort of explained, tried to follow the idea line by line in one of the earlier meetings. But I mean... So this is just intacted sugar? Yeah, but does it really look better than Steadget? No, I think it looks like you have to explain IC. Yeah, exactly. That's also the issue of, do you really want to encourage the serious increased use of tuples?

Do they belong in the guts of liables? Yeah, that's a good point actually. They say that this is the way boost HANA tuples work. I haven't used HANA, but there is apparently a precedent for this. The next paper is something that Corentin mentioned in his Kona article. The title is Zero Initialized Objects of Automatic Storage Duration. It proposes to... Exactly that. It proposes to initialize all the stack variables, local stack variables to zeros. And if you don't want that, you could use a special attribute uninitialized. It's by JF Bastion.

And he claims that this would solve lots of security-related problems, because accessing uninsularized memory is UB. And currently you can't detect it unless you use tools like memory sanitizer. Memory sanitizer is notoriously difficult to get working, because you have to recompile everything with it. This is being discussed. There are two things. It removes QB.

If you use the core guidelines of static analysis that I'm recommending, of course, it will get caught before you start executing without any cost. There's a significant cost if you have a large vector like a buffer and that's why you need the uninitialized. There is one problem I discovered the hard way many years ago. If you default initialize something to zero, zero is the worst default value you can have because it tends to delay the catching of bugs from where zero isn't a good initializer. So that it's hard to find where the root causes. And if you had to have a default value, zero is lousy. I tended to use a bit pattern that was 0, 1, 0, 1, 0, 1, etc. And that caught my bugs very much faster.

But of course, that has even higher cost for initialization. So it's not an uncontroversial issue, but it's being discussed. I think he does mention some other possibilities for the initialization value. It's like FF or some other AA, like hex AA and stuff like that. I think AA or some other value is an equivalent of a CPU instruction that traps at runtime or something like that. Core guidelines simply make sure you initialize all. Actually, Microsoft Visual C uses the CD hexadecimal fulfill arrays or variables in debug builds. And this happens to be the breakpoint instruction as well. so if you happen to jump into that, you'll break. But it's very easy to see that in memory dumps or

in any variables in the debug view. So it's quite helpful to see that, okay, this garbage is precisely this uninitialized garbage. Yes, yes. That's exactly what I did when I had to do it many years ago. Curiously, I seem to remember that Visual C++ compiler initializes uninitialized pointers to something like dead beef or bad food or something like that. Something like that. And I remember the first time I saw it, like, many many years ago I couldn't believe my eyes. What is this? I'm like debugging a program and seeing this in debugger. You just have to have an unlikely value. Yeah. Evil developers will have to memory map something to the deadbeef memory range. So Jeff Bastian provides some benchmarks. Performance impact, he says,

is now negligible. Less than half a percent regression if you automatically initialize all the locals to zeros. And the code size impact is also... The problem is that it's hard to get a good set of grams to measure. But I'm not surprised. If you can eliminate buffers, that's the only thing that I have ever found significant. That's why you need the uninitialized attribute or value.

Next, there were some contracts-related papers that we haven't yet discussed today. This one got updated, a proposal to publish a technical specification for contracts, it gained an introduction and an overview, which is useful. And the overview contains a bit of history. Quote, our overarching goal is to enable the committee to ship a useful runtime contract checking, aka contracts feature in C++ 26. There was a bit of a background about the attempts. We all remember that the paper was killed at the last minute. There's the original. I don't recall that it was discussed. So another one was a proposed plan for contracts in C++ by Timo Dummler and John Spicer, which outlines the steps.

And I think it might have been sort of accepted. There is a table with... Yes, this is basically what a majority of SG21 think is the right way of doing things. Right. So at least there's a plan. Some of us think that is not. They claim it's a minimally viable proposal. I, in particular, claim that it's too minimal to be viable. And that's what my paper says. Right.

The other one was... This is the GABYS paper, Contracts for C++ Prioritizing Safety. Wait for the next version. And the next one is... Deadline the 15th. Questions... Oh yeah, this is the one. Questions on contracts for C++ prioritizing safety. They've addressed the cases where there are unavoidable side effects in contract expressions. As I said, I think the real problem was not addressed, was not realized. There are actually, there seem to be some mentions on the UBE.

I think this paper should also be applied, those questions should be asked also for the other proportion. Some of the questions are good and necessary questions. Oh yeah, there's a whole section, compile time detection of potential UB. So yeah, I suppose. But yeah, let's wait for the second version of Gabi's paper, See what they say. And the last paper on contracts was this one. Classification of contract checking predicates. And not knowing too much about contracts, I thought that it provided useful definitions. I haven't seen that one. Who wrote it? Joshua Byrne. I see, yeah.

Yeah, so it's useful to have all the definitions like what's a contract, what's a contract check, precondition, postcondition, essential behavior, contract violation and so on. Looks useful to me. This is a link that was new to me. It's by Sweden CPP user group and it's a blog row of all the C++ and related articles which is constantly refreshed so that you don't need to jump through all the blogs to see the titles. And thanks to Zdeněk Vilček for the link. And the other useful article was by Polina Alekseeva. It's Top 10 C++ conference talks in 2019-2022. This is on the PVS studio blog which is a static analyzer. There are direct links to the videos and yeah, Vianne's video is number one

and lots of other useful, interesting presentations. CLion 2022.3 released. And some big news in this release are initial support for C++20 modules. Well, given that they use CMake for their meta build system, they must have supported it somehow using cmake i'm guessing but it's a it's a good thing to see and a revolutionary new feature in sea lion is now cmake debugger i don't think it's ever been available anywhere. Basically, you can step through your build

script, which looks like magic given how complex CMake scripts could be. And you can display lots of local, I guess, logic and variables,

which is really nice. Sounds pretty useful, to be honest. Yeah. Lots of people are very happy about it. I mean, CMake is the de facto build system for C++ that we all love to hate. And any help with that is very welcome. Right. I think that's it for today.

And I will leave you with this tweet in response to a question on Twitter. What is a pointer? Tony Van Aert replies, anything is a pointer if you're brave enough. And on that happy and brave note, thank you very much for coming. And I'll talk to you soon. Bye-bye. Thank you. Cheers.