CppCast - Toronto Trip Report

Episode Date: July 27, 2017

Rob and Jason are joined by Patrice Roy to talk about the changes made to the C++20 Draft at the Toronto C++ Standards Committee Meeting. Patrice Roy has been playing with C++, either professionally, for pleasure or (most of the time) both for over 20 years. After a few years doing R&D and working on military flight simulators, he moved on to academics and has been teaching computer science since 1998. Since 2005, he’s been involved more specifically in helping graduate students and professionals from the fields of real-time systems and game programming develop the skills they need to face today’s challenges. The rapid evolution of C++ in recent years has made his job even more enjoyable. He’s been a participating member in the ISO C++ Standards Committee since late 2014 and has been involved with the ISO Programming Language Vulnerabilities since late 2015. He has five kids, and his wife ensures their house is home to a continuously changing number of cats, dogs and other animals. News Diagnostic Improvements in VS 2017 15.3.0 Boost to move to cmake build and test Trip Report: My first ISO C++ Standards meeting Patrice Roy @PatriceRoy1 Patrice Roy's Blog Links Patrice's Trip Report (French) CppCon Course: Practical Modern C++ Sponsors Backtrace Hosts @robwirving @lefticus

This episode of CppCast is sponsored by Backtrace, the turnkey debugging platform that helps you spend less time debugging and more time building. Get to the root cause quickly with detailed information at your fingertips. Start your free trial at backtrace.io slash cppcast. CppCast is also sponsored by CppCon, the annual week-long face-to-face gathering for the entire C++ community. Get your ticket today. Episode 111 of CppCast with guest Patrice Roy recorded July 26, 2017. In this episode, we talk about new VS features and changes to Boost. Then we talk to Patrice Roy, teacher and member of the C++ Standards Committee. Patrice shares his thoughts with us about the recent Toronto C++ Standards Meeting. Welcome to episode 111 of CppCast, the only podcast for C++ developers by C++ developers.

I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? Doing good, Rob. How are you doing? I'm okay. I'm back on my old laptop, which is a little aggravating. I got a new one four months ago, and all of a sudden, all but the top inch and a half of pixels died on me. All but the top? I could see the top inch and a half of pixels died on me so i just said all but the top i could see that's exciting inch and a half yeah i've seen i've seen havesies a couple of times but i've never seen across the top like that yeah that's all i could see the rest was just black it's pretty pretty annoying i would like to say just the honest i know it is kind of exciting

that this is our 11 d first episode. I didn't even think about that. People who weren't paying attention, I believe we had 11D1 slides in our Constexpr All the Things talk that Ben and I did. Was that done intentionally? Well, no, but there were several subtle references to Lord of the Rings in there. And I told Ben, we just have to leave it at 11.1 since that's where it is now. Anyhow. Awesome.

I don't think we'll end up keeping that for CPPCon. Yeah, you've got to have a longer talk, right? Shorter. Oh, shorter. Okay. Well, at the top of every episode, I'd like to read a piece of feedback. This week, we got a couple tweets about last week's episode.

This one was from TJ Chip, and he asked, of feedback uh this week we we got a couple tweets about last week's episode uh this one was from tj chip and he asked is it true that c++ futures have no future and coroutines are the way forward as stated on the recent cpp cast and yeah i i feel like we need to witness a debate on this um gore put in his opinion kind kind of reiterating the points he went over in the episode. I'd love to hear someone like Felix's thoughts on that, since we recently did that talk on his future proposal a couple episodes back. I can tell you that it's a very heated discussion point

at the committee, and it takes up a tremendous proportion of the SG1 time. You know, I was going to say, I bet our guest today would have a comment on that. So maybe we can dig into that more in a few minutes. Yeah, sounds good. If you want to. Okay, and we'd love to hear your thoughts about the show as well. You can always reach out to us on Facebook, Twitter twitter or email us at feedback at cbbcast.com

and don't forget to leave us a review on itunes joining us again today is patrice roy patrice has been playing with c++ either professionally for pleasure or both for over 20 years and after a few years doing r&d and working on military flight simulators he moved on to academics and has been teaching computer science since 1998. Since 2005, he's been involved more specifically in helping graduate students and professionals from the fields of real-time systems and game programming developing the skills they need to face today's challenges. The rapid evolution of C++ in recent years has made his job even more enjoyable. He's been a participating member of the ISO C++ Starens Committee since late 2014, and has been involved with the ISO Programming Language Vulnerability since late 2015.

He has five kids and his wife ensures their house is home to a continually changing number of cats, dogs, and other animals. Patrice, welcome to the show. Hello there. All right, Patrice, now that we've introduced you, let's dig in for a minute about this coroutines versus futures and how much time it takes in the committee. In the committee as a whole, not that much, because it's pretty much tied to the workings of SG1.

It's a heated topic, because you've got some big names that have written position papers on that one in recent months. Sean Parra has written something. You know Gore's position. Gore's work is tremendous. Can you remind us what's the purpose of the SG1 group? It's the concurrency and parallel programming group.

They sit down and talk about this, executors, memory model stuff, atomic slashes, barriers. I think there's been more than a day. I wasn't there's been more than a day, I wasn't there, but more than a day on futures only at the last meeting. Wow.

Yeah, because there's many competing proposals and points of view over that. We know that the ones we have are suboptimal for a number of reasons, but they are there and they work. I use them for some stuff, but I agree that we can do a better job. So maybe at the risk of asking you to, I don't know,

burn some professional bridges or something, do you have an opinion? I wouldn't throw futures in the garbage for a moment. At least as a teaching tool, they are useful. They can do cute stuff. They might be underspecified. Yeah, you can do cute stuff with that. They are underspecified a bit.

I mean, I'm sure that some people would use them if they knew for a fact that it uses a thread pool. Right. But they won't because it's not specified as such. And we don't have thread pools because we don't have executors. And executors are the way we want to go for that. But they're not ready yet. So for a number of reasons, it's not exactly what we want, but it still works.

And we have something to teach and something to use. Coroutines are going to be awesome. I don't know if they will replace futures completely. I'm looking forward to coroutines, but we have futures, we can use them.

So that's already something. So do you agree that coroutines can do everything that a future could do? You had words from a much better, much greater expert on the topic last week than I am. Yeah, okay. At the same time, he has an understandable bias.

But he's a great guy, and I'm sure that his opinion is worth more than mine in this topic. I would hold both for the moment, but I'm sure that futures will change and evolve because there's so much work in that area right now. Well, I mean, from a personal perspective, I've never used a coroutine, but I have used futures, and I do find them handy when that's the kind of thing that I need. The thing with coroutines is they're very light. So you can run a huge amount of them and it doesn't really show up on your CPU and memory usage.

So the lightness of it is very cool. Whereas with futures right now, I might be corrected by SG1 people, but I think they end up mapping to a single thread and they are stackful so they consume more resources. So if you want to compete with Go and the Go routines, you're probably better with the coroutines that Go has put up than with

other mechanisms. That being said, there's two kinds of coroutines. There's Go's coroutines and there are library-level ones that are different a bit, so it's not a clear-cut topic. There's at least two competing approaches there. There's a boost implementation of a library-level one, is that correct? Yeah, and I think that what's being proposed for the standard is based on that, but again, I'm not the expert for that one. Oh, so there are currently competing standard proposals even. I get the feeling that the language level 1 will win, but that

does not necessarily include the other one, and there's valid points that one can make to keep the library level 1 2, maybe under a different name, I don't know. Okay. There's a lot of work in SG1.

Okay, well, we got a couple of news articles to discuss, and then we're going to talk more about the Toronto trip report, okay, Patrice? Okay. So this first one is updates coming in Visual Studio 2017 15.3 update, and this is a bunch of diagnostic improvements, which I'm sure are going to be quite handy. Changes with bring compiled headers, empty declarations, which I thought was interesting.

They could be used in template metaprogramming, and people are running into problems with that. Is there anything you guys wanted to call out in this one? Well, I tried it. I installed it, tried it. I ran it on my PhD code, which is a big chunk. It's actually quite cool. There's one thing that annoys me there,

and annoys me with Clang too, is the warnings for moments where you are initializing your member variables in a different order than the order in which you have declared them. Because I don't really care. I don't make them interdependent. But I understand why the warning's there. It's an okay warning. It's just bugging me because I wouldn't care that much I don't make them interdependent. But I understand why the warning's there. It's an okay warning.

It's just bugging me because I wouldn't care that much in my code, to be honest. One thing I noticed with this is that this compiler update shipped with stdbyte. And shipping with stdbyte means that if you compile your own code and you included a platform header of some kind and you had a using namespace std in your code,

you end up with a lot of errors that are easy to remove. You just remove the using namespace directive because otherwise you end up with a fight with std byte and the byte of your platform, whatever it is. Interesting. And I find it fascinating that the one that you called out is the warning that I'm the most excited about. Because that makes, having worked on cross-platform teams,

and GCC and Clang are so willing to warn on you initializing members out of order. And then if you, but if part of your team is only working on Visual C++, then you end up with hundreds of warnings when you go to compile and you're reordering everyone's initializers. I'm happy that it warns because sometimes there is reason to make them interdependent on each other. I'm okay with this. It's slightly

annoying, but I understand it's a worthwhile thing. As you did, I standardized my ordering on all the compilers to just make it go away, so that's okay. I'm also fascinated by the second warning that they mention here, that it will suggest to you to use if constexpr,

if it's something that is a constant expression, constant conditional. I didn't even know the Visual Studio supported if constexpr yet. Yeah, it has for a little while, but it's an awesome warning. That one is really, really cool. Yeah, that's a great one. I don't even know if any of the other compilers, I don't think they do, are doing a similar warning yet. I like that. I'd give them a few weeks and they will all do this.

If one of them does it, they're all going to do it. Right. That's true. Okay, next one. Big change. Looks like it'll be coming to Boost. They're going to move from their proprietary build system to using CMake, which sounds pretty exciting. It does.

It sounds exciting to me. I'm such a child when it comes to CMake. I've barely touched it. I'm an old schooler. I used Make and very old tools. So everyone talks about it. I know so little about that. One thing I know is that I tried to compile and install Boost a few years ago.

It was painful. It was getting nicer. And I'm sure this is a good move, but I'm sure that all of you have better opinions than I do on this one. You know, CMake is the tool that everyone loves to hate, and that's fine. It's also the tool everyone uses.

It's the tool everyone uses, and having to throw Boost Jam into the mix when you're building a large project and you want to be able to build everything from scratch, it just adds to the complexity of your build system. Which is already a big beast in itself. Yeah.

Okay. And then this last article is a trip report from a guy Davidson who we've talked to before, and this was an incredibly detailed trip report. I definitely would encourage all listeners to read this if you're interested in how the, uh, the ISO meetings go. Instead of focusing on the results of the meeting, which most trip reports seem to do, he really did a breakdown day by day on what the process is like,

which I found to be pretty interesting as someone who's never attended an ISO meeting. The guy is an awesome guy. Let's start with that. It was his first meeting. I went for a beer with him the day before because I was glad to see him. Knowing that he could actually vote

and participate, he was ecstatic. He's been going all over the place. He's been participating in everything. He's very enthusiastic all the time. Really, it's a cool report from a very, very cool person. We're all better for him participating in this. I hope he'll be able to go

to the next ones too. There's two quotes that I really liked from his core work because he came for a morning with us at core, which is a very different experience because we're not screaming at each other or throwing tomatoes or anything. So there's a thing where he says, after a discussion in the other groups,

the silence was deafening, broken only by the thrum of the air conditioning actually whispered to someone. This is lovely. Effectively, if you go from evolution, there's a big room where people cut each other sometimes because they're all very intense, and you go to that very cerebral

place, it's for some scary, for others, a very different thing. And the other one I liked was where he said, I made my first direct contribution to the standard because I corrected the use of an indefinite article from an N to an A. My delight was observed by the project editor for which he offered a fist bump. It was a glorious moment. But he said that is true.

There's no pedantry in core. It's all important. We work on clarity and we reduce ambiguity, which is exactly what we do. So it's not for everyone, but I'm glad he didn't stay. But I'm glad he liked the little time he spent with us. Well, I mean, it sounded like he was trying to spend some time in every working group, which would have been quite the task, it seems like. No, no, it's the thing to do.

If it's the first time you go somewhere like that, you should try to sit for at least half a day in each of the places that you can go to. Maybe not all the study groups, there's too many, but it's a very different experience from place to place. It gives you a better idea of what the committee is. Even if you don't contribute much, even if you just listen, make some small comments,

but the fact that you're there and get a feeling for it is cool. There was another guy whose name escapes me, a professor from New Toronto, who came in with us and just worked and took notes and discussed and that's what we suggested. We told him, like, go around, talk to people and sit in different rooms. Get a feeling for the thing.

So it's better than sitting in the same place for the whole week, at least for the first time. Sometimes you are surprised by the places where you feel more comfortable and more useful. So try it. So it looks like Albuquerque is the next one, which I really wish I could go to because that's a pretty easy drive for me. But, well, I guess I'll be in Berlin instead, so I'll take that sacrifice. But it looks like they've announced where the next upcoming ones are for people who are interested which I did not see these posted previously

it's very recent stuff Florida in February, March I think we go to Rapper's Will next summer yeah, Switzerland that one is a bit costly we have to put money away there's a few

there's talk of having maybe two. We tend to have two in the U.S. every year, continental U.S., and one somewhere else. This year it was Toronto, which is somewhere else in the U.S., even though it's very, very close to the frontier and to the border. And there might be two in Europe in 2019 or 2018 or something. There was talk of one in Northern Ireland. There was talk about one in Bulgaria, maybe, and maybe one in Frankfurt or somewhere in Germany.

Oh, wow. Like Cologne, maybe. But there's nothing official because for some U.S. residents, it's difficult to go outside sometimes. So, we'll see. Well, it's not necessarily getting any easier for our foreign friends to visit the United States either. That's true. Being one of the foreign friends, I can

attest to that. But Toronto is extremely convenient for you, right? I went there by train. It was a nice ride. It took me five hours. I could work. I had Wi-Fi. The only problem was that the train was trembling a lot because the tracks between Toronto and Montreal are shaky a bit, so red wine was spilling all over the place, and it was complicated.

Oh, that sounds terrible. Well, you get off the train, you're a bit dirty. And the nice thing about Toronto is you can walk everywhere. It's very easy to walk from the hotel to the university. It's about a 15-hour walk. It was warm a bit, maybe, but it was a nice week. So yeah, pretty convenient. I've heard that parts of the Canadian Railway

anyhow can be very beautiful. I haven't done any of that myself. It's hard to tell. I've been working all the way in and all the way out, and I've been working all week. I didn't look at much stuff apart from buildings. At a meeting, you work from 7 in the morning to like 12 in the evening. So you don't see much.

You just work all the time. Wow. Crazy. Okay, so speaking more about Toronto and the actual work of the ISO meeting. So most of the work, from what we can see, was related to C++20. Is there anything left to do on C++17?

We cannot add anything. The ballot is ongoing right now. My understanding, you have to understand that this is my first ever standards participation in this case. My understanding is that if there's no national body that complains, it will be a standard before Albuquerque.

Okay. Now, take this with a grain of salt. It's my understanding. I might be making mistakes, but that's pretty much it. If there's at least one national body that has a singular problem with it, I think we have to re-ballot things afterwards. And then it's not a unanimous vote. It's a vote that has less than so many complaints that we need to have. There's a different name.

We don't expect that to happen. We expect defect reports to come in, things to fix, but we don't expect people to reject the standard in its current form. So it might happen, but I would be surprised. So barring nothing coming up, you expect it in the next two months or something like that. Yeah, well, it's an administrative process. So, it's the ISO rules that are being applied right now.

And it's between Switzerland and the rest of the countries. It's going to come back at some point. We're going to get an okay. Everyone is reading it, voting for it. So, it's out of our hands right now. Okay. Okay. So,

last week, one of the things we talked about a little bit was that the verbose syntax for concepts was accepted into the C++20 draft. What are your thoughts on whether the other syntaxes are going to be accepted as well before C++20 is done? It's funny, you know,

in Toronto, it was a thing we talked about a lot too for some reason. Concepts took a lot of time. It took more than, maybe not half of Core's time, but almost. It took an entire day and an entire evening session

for Core and Evolution together. There was a lot of work for that. I'll first tell you that I'm very glad that we now have concepts in the proposed standard for C++20. So this is, I think everyone voted for that. We were glad to have that at least, even if it's not the complete thing. There's more than two syntaxes. There's two terse ones that didn't go in right away,

and there's a few more verbose ones. A few more. Yeah, well, there's layers to the degree of detail you can put in there, and the two more succinct ones didn't pass, but the others did. So it's not one over two. It's more complex, maybe like three over five that passed in. There's one that I have a bit of trouble with myself, with braces that I find difficult to read.

People are complaining that it's hard to grep for also, so it's hard to find what you wrote. Grep I could live with, but I find it difficult to... For such an abstract concept, just a few symbols and a pair of braces, sometimes it's not easy to read. So this one is not in yet. And the one that I personally like, Death Stars 2, is one where you can use concept names instead of types.

Like you can have F takes a number and a number and returns a number or something. That one didn't pass because of were a few issues with it. I expected to come back at Albuquerque and other meetings, but there's a number of open issues, like if you have F of auto and auto, you can pass two different types,

but if you have F of integral and integral right now, you cannot have an int and a long as far as I know. You must have the same type for both. So there's a few things like that that in the current specs are hard to justify maybe, make sense to some, annoy others.

That's why there's no consensus over the feature. You have to understand that we voted for that syntax, but it was a very weak for, so there's no consensus. Majority is not sufficient at the committee to make this thing pass. So I want to take a minute.

So you said, if you can just use a concept name as if it were a type name, like number. So yeah, I've seen like some tweets about this. And since I haven't really been following concepts, I wasn't sure if I fully understood. So some people are saying if it's a number and a number, then they could be two different integral types or whatever that happen to match the concept of number. And some people are saying if it's number and number, then they must be the same type.

Yeah, but when you have auto and auto, there's no constraint that's saying that you have to have the same type in both cases. And auto is supposed to have the same type in both cases. And auto is supposed to be the most general concept. So there's disagreement over this kind of thing, which tells us that maybe we haven't clarified really what we intend with this. So there's a weak form, but it's not a strong enough form to make it go forward as is.

But we still have a few years before C++20. If we make a lot of use cases, look at it in more detail, and are more convinced as a group of what we expect from this kind of syntax, maybe it will pass. When I was at my first meeting, we had accepted

a comment from a country that suggested that we can return a sortable, say, from a function, so have a concept as a return type. And it had been implemented, and it worked, but the compiler people, mostly, I think, are of the opinion

right now that there's too many obscure cases to take the position that the feature is fully cooked. They're not against. They want it to be better specified. That's my understanding.

We currently have the precedent already with generic lambdas that you can have two different things called auto that are different things. That will work also with concepts. Okay. Yeah, it does seem like requiring two different things called auto to be the same thing wouldn't be consistent, but I definitely also agree that it been introduced by Louis Dion, which is you can have a lambda that's constrained, like lambda that takes a T and then TT instead of auto, auto. So you can have generic lambdas

with specified template types. So that you can now constrain two types. This is not very far from the concept thing. So maybe guidance from one would lead into clarifying the other. When you work with concepts, it's very abstract stuff. So it's important, I think, that we agree on what we intend and mean with that thing because it's going to be used all over the place.

Concepts are a game changer. So Louis' paper on constrained lambdas, that was accepted, correct? As far as I know, we worked on it, and we proposed it, and people voted for it. Okay. Yeah. That's an interesting one. Yep, yep, yep. It's going to be useful.

Yep. What are your thoughts on some of the other major TSs, like modules, coroutines? We talked about it a lot last week. But do you think some of those are going to get voted into the standard draft at Albuquerque, maybe? I don't know when, but I expect modules to go in. There's so much work being done on modules, and in Code Another, there was still a lot of obscure cases, but things have gone forward,

and we're really, really close in this case. We spent more than a day at core, again, on the modules wording. We clarified a few things. It's really starting to make sense from everybody's perspective. There's been great work. Gabby has done great work with this, Richard, and everything.

Modules I have sincere hopes for. Core routines I hope too, but modules and concepts I'm pretty sure we have something for C++20. Big things. It would be maybe one of our listeners who's interested in this kind of thing could set up a betting pool of when we expect each thing to get voted in.

One thing you can expect is you can expect bigger features because we collectively agreed that we want we will spend less time on the little things and more time on the big things for this one because we really want them to pass through. So expect maybe less library features or something

because there were a lot of them in C++17. But a few big things in the language, it will change the way we code, which is pretty exciting. According to Guy's trip report, it looks like a lot of effort was spent on ranges. Oh, yeah, yeah. It was in Library Evolution and Library a lot. They reviewed the wording for days.

Library does a lot of the wording in the standard. The upper end of the wording, the high number pages are there. Score does the low number pages. And ranges were a big thing for them. So it's one of those that everyone has been looking for for a long while and really wants to use. And it's a good testbed for concepts, too, because they have conceptified, in a sense, the wording.

So if it works there, we're hopeful we're going to be able to spread out the thing all over the place. Am I correct in my understanding that for ranges to become a TS, concepts had to come in first because it relies on concepts? It would have had to be rewritten otherwise. It would have been full with enable ifs

all over, and I'm pretty sure that they will be very happy that both come in at the same time. Okay. I wanted to interrupt this discussion for just a moment to bring you a word from our sponsors. Backtrace is a debugging platform that improves Okay. first and only platform to combine symbolic debugging, error aggregation, and state analysis. At the time of error, Bactres jumps into action, capturing detailed dumps of application and environmental state. Bactres then performs automated analysis on process memory and executable code to classify errors and highlight important signals such as heap corruption, malware, and much more. This data is aggregated and archived in a centralized object store,

providing your team a single system to investigate errors across your environments. Join industry leaders like Fastly, Message Systems, and AppNexus that use Backtrace to modernize their debugging infrastructure. It's free to try, minutes to set up, fully featured with no commitment necessary. Check them out at backtrace.io slash cppcast. One of the things you mentioned before the interview was the Programmer's Bill of Rights. Do you want to tell us a little bit about that? Yeah, but I can't tell you much because it hasn't gone forward much. What I can tell you is that the committee is looking at the way it works. It's been doing that for a little while now.

And it's also looking at the way the language evolves, because we're moving too fast for some and not fast enough for others. for a little while now. And it's also looking at the way the language evolves because we're moving too fast for some and not fast enough for others. So yes, some people are not at C++11 yet or will stay there for a while. And some people are hoping that we go on a faster than three-year cycle, which I don't think we will because we would never get anything done if we did that.

So the idea of a bill of rights and of a bill of responsibilities that they would go together in this case is us telling people, here are your rights. So here is what you can expect from the language. Here is what we will keep stable. Here is how we will deprecate things. Here is what you can count on. Here are the rules, really. And on the other end, the responsibilities are, this is what you should do

if you want to survive language changes. So when we change things, if you have respected those rules, you haven't cheated the system by adding names into a CD, for example, well, expect your code to keep on working or be manageable when we change things. Because if people want change, we have to have a lifecycle management of some sorts.

But it's a spec. It's not a product that we have. So this is where we're going. We want to tell people better how to write their code such that their code lasts and in such a way that we can evolve the language and they can keep up with the pace. So do you expect that, for the most part, these would fall into things that compiler warnings and static analyzers would already be catching, or do you expect maybe there would be new tools

to help make sure people are programming in a way that can be portable forward? You can expect both. People have even talked about standardizing some warning messages, but it's something that's floating around. There's nothing official in there. We're just talking right now.

But we want programmers to, when you see that warning, well, you know you've made a blunder or something, but you know what it means. It's almost codified in the standard, and you can actually make your code work for all compilers if you respect the rules properly. We want to make it clear for people. There's so many people who have beliefs about volatile

and STD that are completely wrong, but they're using proprietary extensions or what have you. We want people to write code that lasts and we want the language to evolve faster. That's the way I think we're going to go. We're going to write code that lasts, and we want the language to evolve faster. And that's the way I think we're going to go. We're going to tell you what to do and what you can count on,

and we hope that we'll do this right. There's a group that's working on that right now, but it's evolving, it's all new, it's all fresh. There's nothing official right now. So what we're doing right now, we're talking about things that are in the air and the things that are written. Interesting.

I only just this week saw a place where I personally thought a standardized compiler warning would be awfully handy. And that's using standard move on a const value, which is almost 99% of the case not what you meant to do. Yeah. What would be the use in this case of a standard message instead of a custom one? Well, just, well, okay, that's a good question. I don't know, I hadn't really thought about that, but it seemed like something that all tools could usefully warn on. Yeah, I understand that. Well, I think it's exciting news that we are looking at ways to take the evolution of the language

in our hands as a process and get people better through that such that their code evolves better. I think it will help both those who think this is moving too fast and it's crazy and are a bit scared of what's going on. So they're sticking with old compilers and old tools

and old ways of doing things, whereas they could really do better today with what we have. And it will give confidence to people who want to go forward. So I think it's process work, but it's exciting news. Okay. You also mentioned some work you're doing with SG12 and the Undefined Behavior Study Group. Do you want to tell us about that? That was one of those I was looking forward to when I went to Toronto. WG23, which I think we've talked about before, is a much smaller group than WG21, which is the ISO C++ committee. WG23 works on language programming vulnerabilities.

They're publishing a big document that tries to do cross-language explanations of things you should not do. It's been perceived as something attacking C in some circles because there's so many ways you can put yourself in trouble when you're doing C code and C++ was seen in such a light, under such a light also because it's seen as some kind of C with other features

by some who don't program in C++ very often to be honest because they are two very different languages today. Being in Toronto, and the convener of WG23 being from Ontario also, also the same province, we had the chance to actually meet with him in person, in this case. So he went with us to the CN Tower because we had a reception there on Wednesday night.

And he went working with us on Thursday afternoon. It was a relatively small group, maybe 15 people or so. Bjarne was there, among others. I was there. Where Stephen Michel, the convener of WG23, explained what this group does. Gabby Los Reyes, the chair of SG12, explained what SG12 does, their perspective. Bjarne talked about security, vulnerability, and good practice from the perspective of the language of C++,

what we're trying to do. So now the thing is, instead of going to don't do this, it's bad, we're trying in C++ to tell people, even though you could do this, do this instead, it's better. We're trying to show good practice more than bad practice. We're trying to, we know that people can go around the good practices and do their stuff if they want to. We are not going to remove that from them because sometimes you have to do what you have to do. It's a systems programming language.

But we are trying to get people to doing better code. We have the GSL, the guideline library that is working well with static analysis tools to refactor things for people. We have the Clang utilities. We have a number of books

that try to tell people, you should code like this instead of like this. Not only is it shorter, but it's faster. It generates better code. It's safer for you. So if you really want to put yourself into a bubble, you can do it, but you can do better now. So we're trying to put together

a joint venture with WG23 and SG12 where instead of writing an annex to with WG23 and SG12, where instead of writing an annex to the WG23 document that says, this is bad stuff, we're going to promote proper ways of doing things in C++. To make things easier,

we're also trying to co-locate with them. So we expect, as far as I'm concerned, it's going to work. We expect WG23 to meet in Albuquerque at the same time we do in November so that we can spend a day or half a day with them together to get a better grasp of what each group does and make things go forward together. It's pretty exciting news, to be honest, because the two groups haven't spoken much with one another for a long while.

There's a few C++ people around WG23, but we're not numerous. It's mostly Ada. So, yeah, I think it's good for them because we're a very big group and we have more resources. And it's good for us because it will give us

an avenue to tell people how to write better C++ code. I just want to understand this WG23 group a little bit better. It's a group of programmers of different languages that put out just general recommendations in the form of some paper at the end of their process. I mean, they're not making specific suggestions to a language governing body, you know, you shouldn't do this. It's just general recommendations?

It's more tricky than that. When there's a standard that's published by ISO and you're using a language that relies on that standard, you are committing yourself to respecting the rules. So you could be sued if you're doing dirty jobs. You are committing yourself. So these guidelines are actually useful for those who are paying you

to do the job because they know what they can expect and they're useful for you in order to do your job properly and avoid all the legal assholes you could get if you're doing a messy job. So WG23 is doing useful work. They're much smarter than we are, as I

said, so they cannot go forward as fast. And they're trying to have a per-language annex. And there's a few already existing, but there's no C++ annex. It would be big. It's a very big language. Most of their annexes are, as I was saying, don't do this.

And we're trying with C++ to go another way. This is a work in progress, of course, but it would be different the next bit and it would promote good working practices. That's interesting. It looks like they have a lot of documents they've published that one might find interesting to browse through. Yeah, well, it's public stuff.

You can go on their website, WG23, and you'll see a number of things. We're about 130 people at the C++ meetings. At the WG23 meeting, there's less than 20 people. It's not the same scale at all. But co-locating is interesting. They will be able to do their own thing.

We'll be able to do our own things. And getting together for some time, I'm sure we'll make a lot of progress together and yeah, it will make the language shine a bit There's one here that I think our listeners might be interested in because everyone likes making their own language There's the overarching language designer advice document

I haven't read it so I'll believe you language designer advice document? I haven't read it, so I'll believe you. Every time I've spoken with them, I've been remotely to a few meetings. They're trying to make the big document with the vulnerabilities public and up-to-date. They're working on things such as you have enums, you don't want to use values that are not in there, what do you have to be careful with,

what are the pitfalls, you're using objects, so use after free, use after delete are bad, calling a function on a null pointer is bad, or whatever. Some of them are very easy. Some of them are interesting. Sometimes they have trickier things that they warn you about.

I doubt anyone would read the paper from beginning to end. It would be depressing because it's only bad stuff. But if there's a feature that you think you don't understand well enough or you have worries about, it might be interesting to read the sections on it to avoid getting into trouble in general. Cool. Sounds exciting.

SG12 is a small group also. Undefined behavior is not for everyone. It's not something that excites everyone. We did have a very good afternoon with SG12 because apart from that, we had a great presentation by Lisa Lepincott, which is always awesome.

It's always thought-provoking. A reflection on assert and the meaning of assert in programs and the way she sees that relies on treating the abstract C++ machine as an actual machine with parameters. She really has an interesting way of seeing things. So if you want a thought-provoking paper, Lisa Lepincutt is a very good one. And we also processed a very small one, but that

should seem evident to everyone, but doesn't work right now. The fact that you can memcopy into an object and that would begin the object's lifetime. So you have an uninitialized object, you memcopy the bits into it and you don't have to do new. The object is presumed to exist

after that because memcopy is special. It's something that lots of people do, but that's not legal. It just works by accident, but it would be nice that it works because it's mandated to work. I have mixed feelings about certain functions

that are considered to be special and come into play when we're talking about alias rules and object lifetime and that kind of thing. Memcopy is a special beast. Go ahead. Just to finish the thing, SG12 is a group that tries to remove undefined behavior cases where they should not exist. So it group that tries to remove undefined behavior cases where they should not

exist. So it's exploring things that are undefined behavior, and it's trying to reduce the set. It will never be an empty set, but every time there's something like this that everyone does, it kind of makes sense, and you're wondering, why doesn't it work? Well, if you can make it work, why not make everyone's code work properly?

Okay. So what haven't we talked about yet? What do you think has been kind of overlooked from the Toronto meeting that you haven't seen discussed much? The thing that I found the most interesting in my week, it's a feature that looks small, but when you think about it, it's very tricky to grasp, is the SIMD operations.

So Pablo Alpern came to core with wording for what he called wavefront policies, if I remember properly. So the thing is, if you look at the way the machine works right now, the abstract machine, there are things such as sequence before that says if A is sequenced before B, well, A occurs before B. So it gives you an idea of how your program should be ordered and what the reordering rules are when you have threads and everything. When you enter the vector operations that do many things in a single thread, time gets screwed up because there's more than one operation occurring at the same time in a given thread.

So the rules are completely different. And the way the compiler can optimize your code is very different too. So Pablo was trying to express the idea that when you have a loop that's being vectorized, you can give some leeway to the compiler in order to reorder things to make them faster, but you cannot do

everything. So it's kind of like taking the time that's 1D and making it into a 2D kind of time and having a staircase in there that gives you the range of places where you can play around. It's very thought-provoking, I think. When you're playing with the concept of time in the actual language, you have to take a step back and say, oh, this is deep stuff. So we're going to have lots of very interesting optimizations, but wording that, it's very tricky. Sequence before makes no sense with that, because you have to rewrite it to say something like, not A occurs before B, but the end of A occurs before the beginning of B, because

they could overlap. So yeah, it was surprising. I didn't expect that to make my day when it happened, but it was very interesting. So I think Guy's article also said that there's been some movement on contracts.

Yeah. I don't know where we're going with that. There's at least two big efforts. I haven't been to the contracts meetings. So the only thing I have is hearsay. When I was in Kona, I had a chat with a few people after the meeting and they were telling me

that there were still open issues as to what do you do if there's an exception raised in the contract clause? Do you terminate the program? Do you recuperate? How do you do that? You have those attributes that are saying you expect this and you require this or whatever. I don't know what their names are. And you put code in there. So if you evaluate the code that raises an exception, what do you do?

So maybe there's an answer to that today, I can tell you. But these were open issues. Lisa's work with the assertions tied into that also. She had in her perspective the idea that if we clarified what assertions are, we would make better contracts. So I hope to see them in C++20, but I don't know what shape they will be in. I haven't been close enough to that.

The guy who works on that the most, I think, is Juan Daniel Garcia, or Jose Daniel Garcia. J. Daniel Garcia is a professor from a Spanish university. He does a lot of work for the committee. I don't know how public he is, but I think

he could give you more information than I do, or John Lakos maybe, or one of these. Okay. Okay. So you're going to be speaking at CVPCon this year. Do you want to tell us a little bit about your plans there? Yeah, I'm very lucky because a lot of tremendous speakers haven't managed to get in. I've been lucky. I have two talks coming up. There's one that I tried at the C++ users meeting

in Montreal there two months ago. I thought people wouldn't be interested because it's a bit abstract. It wasn't the abstract machine of C++. People don't know it exists in many cases. But when you're programming, you're not programming for a PC or for a Unix machine. You're programming for some kind of abstract machine where there are rules.

And the wording is a bit obtuse. But it's fun when you think about it to know what the machine does, what it doesn't do, what guarantees it provides to you. So I did a talk on that. It was actually pretty well received the only thing that was strange is that when you're going to that level you talk about Atomics and you talk about memory model and everything and when I was preparing the room and saying hi to people coming in

there's a guy named Jeff Prishing that came in and I don't know if you know this guy but he's one of the top notch people about Atomics in the world Jeff what the hell are you doing in this room he said I came to learn hey but he was very top-notch people about Atomics in the world. So Jeff, what the hell are you doing in this room? He said, I came to learn. Hey.

But he was very nice. He's a very nice guy. He used to work with Ubisoft. He's doing something else now. So yeah, so I was lucky because I knew a few people in the room already because I've been teaching for a while, it seems. So the more I know the audience. But it went well.

So this one was accepted. I'm going to adjust it a bit because of Lisa's ideas that I found very interesting. And I had a follow-up kind of talk that I proposed to, which is a bit tied to the first one. And it's also tied to what I do with SG14, the low latency group. A talk about trying to get a feature in that we need and want, but that just doesn't fit well with the language as it stands. Namely, we're trying to let users specify things about threads when they construct the threads. They're called

thread attributes right now. It's something that Vicente from Nokia has worked on. I have worked on it a bit also. If you look at the threading API that we have right now in the language, you can create the thread and then get the native handle and play with it and call operating system functions. But when you create the thread, there's nothing you can do. There is no option. That means that, one, if you have a problem, you get an exception.

So the non-exception users will not use it. And two, if you want to specify such things as a specific stack size, there's no way to do that because it's too late when the thread exists. But it's hard to tell a thread about an expected stack size when there's no stack in the standard. Because if you look for the word stack in the standard, you'll see std stack and that's about it.

Interesting. There's no stack in the standard. And that's good because Gore's work doesn't require a stack. You guessed last week. So if we impose the stack, his work would not be as efficient. It's good for many things. There are machines with more than one stack per thread, as you own people have told me about that.

But we do need a way to specify this. So there's many ways to go around. There's many pitfalls. And it's something I've been working on for a few years now. It's going forward. We're going to end up with something at some point. But it's an interesting process. So there's a talk that I will be giving there.

That's how do you make a feature go into the language where the language is resisting and it's not a natural fit. So I found the topic to be interesting should someone else have to go through that. So yeah, so these are my two talks. And I give a class too, a practical class that's going to be after the conference. I gave one before the conference last year.

It was well attended and I had a lot of fun with it. This year is going to be a post-conference one. I'm going to be competing with a guy named Turner who's an awesome, awesome instructor, so it's going to be difficult. But I hope people will still come and see me. It's going to be how can you take existing problems that you can solve with traditional C++ code,

but then there's this whole new tool set that you have with C++ 17 that's filled with cool stuff. So what can you do even better and make your life nicer? And how can you make this new stuff come to light and make your programming task easier and more fun? So very practical stuff. Those who come in, bring their laptops. We'll do portable code, of course, because I don't know what laptops and computers you have. And yeah, we're going to be coding based on problems

that we're going to try to fix with old school techniques and then see how the new stuff comes in and makes our life better. So specifically about moving stuff to C++17, actually, effectively. Yeah. to C++ 17, effectively? Yeah. About 14, 17, depending on people. Okay, I was going to say, you said that

you're going to do it in a portable way, and I'm thinking the compiler compliance for C++ 17 is kind of like this still all over the place. So I'm going to wait a bit before I tell people what's the lowest mark for them, because I don't want to tell people, you should, right now, today,

choose this or this compiler. I'm going to wait until maybe a month or a few weeks before and tell people, well, if you want to bring GCC, try to have at least that version. Otherwise, you won't have as much fun with us. And if you bring Clang, try to have at least this. And if you want to use VC to this, if you have something else, please make sure

there's at least these available. At worst, I'm going to do this, if you have something else, please make sure that there's at least these available. At worst, I'm going to do demos, but it's more fun when people have their hands on the keyboard and there's interaction. Yeah, with any luck, looking at we've got two more months effectively, we might get one more release from the Visual Studio Compiler team by then.

Yeah, they're very efficient people these days. They're very productive. I appreciate what they're doing. They're definitely moving fast. Okay. Well, your teaching class sounds really interesting, so I look forward to that. I hope people will like that.

I had a lot of good feedback last year. I like teaching. It's my day job. And the people at CppCon are very interesting, very talented, very bright. So I expect two very pleasant days with them. Yeah. Sounds like it'll be fun, yeah. Although I will miss your class, sorry.

Well, we should have a coffee or a beer at some point. Definitely. Well, it's been great having you on the show again today, Patrice. Well, thank you. Very nice. It's been a great meeting last week, two today, Patrice. Well, thank you. Very nice. It's been a great meeting last week, two weeks ago, Toronto. I'm looking forward to Albuquerque. I think we have a great language coming in, and I think you can expect C++20 to be awesome.

Great. Thank you. Thank you. Thanks so much for listening in as we chat about C++. I'd love to hear what you think of the podcast. Please let me know if we're discussing the stuff you're interested in. or if you have a suggestion for a topic, I'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. I'd also appreciate if you like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at

Rob W. Irving and Jason at Leftkiss on Twitter. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode is provided by podcastthemes.com.