CppCast - C++17 Kona Update

Episode Date: March 30, 2017

Rob and Jason are joined by Patrice Roy to discuss the state of C++17 after the recent ISO Standards meeting at Kona. 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 Herb Sutter's Trip report: Winter ISO C++ standards meeting, C++17 is complete Botond's Trip Report: C++ Standards Meeting in Kona, February 2017 Software Engineering Institute Makes CERT C++ Coding Standard Freely Available C++ Now 2017 Program Available Patrice Roy @PatriceRoy1 Patrice Roy's Blog Links C++ Standards Consistent comparison (Herb Sutter's Comparison Proposal) Sponsors Incredibuild JetBrains

This episode of CppCast is sponsored by Incredibuild. Accelerate your C++ build by up to 30 times faster directly from within Visual Studio 2017. Just make sure to check the Incredibuild box in the C++ Workload VS 2017 setup. And by JetBrains, maker of intelligent development tools to simplify your challenging tasks and automate the routine ones. JetBrains is offering a 25% discount for an individual license on the C++ tool of your choice, CLion, ReSharper, C++, or AppCode. Use the coupon code JETBRAINS for CppCast during checkout at jetbrains.com. Episode 95 of CppCast with guest Patrice Roy, recorded March 29th, 2017.

In this episode, we discuss the C++ coding standard and the CPP Now schedule. Then we talk to Patrice Roy, a member of the C++ Starens Committee. Patrice shares his thoughts about the state of the C++ standards after the recent Kona meeting. Welcome to episode 95 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? Pretty good, Rob. How are you doing? Good. You have some more news to share, don't you?

I guess. I didn't know we were going to talk about this necessarily, but it looks official that I will be speaking at Pacific++, the first C++ conference in the Pacific region, I guess is how it's being billed. It will be in Christchurch, New Zealand in October. Very cool. So for the Australian and New Zealand C++ community, basically? Sure. I don't know why anyone else in the Pacific Rim maybe could come to.

Fiji, you know. Awesome. And when is that going to be? October 26th and 27th, I believe, are the dates. Very cool. Very cool. We'll have to put a link to that on the website for this show too in case anyone's interested in that i know we have some listeners in that area i'm sure i'm sure okay well sorry for episode like three piece of

feedback uh this week we got an email from drew he wrote in hey guys just wanted to drop you a line to let you guys know i've just found your podcast and I have been enjoying listening to the most recent episodes. I'm coming from a background in computer-aided design technology and have been studying a few programming languages for the past decade. I'm now looking to focus entirely on C++, though, and I'm wondering

if you've had any discussions in previous episodes revolving around geometry, solid modeling, coordinates, graphics rendering, etc. that you could recommend I listen to. What do you think about that, Jason? I know we had probably a couple episodes that fit into these topics. We had the one guest who worked on the 3D graphics for movies.

Yes. That was a while ago. Yeah, that was a while ago. and i'll have to look up what episode number that was i would have to also and we also had the one with using um uh underwater sonograms for mapping of yeah minerals right yeah the games people do that stuff all the time yeah we have uh yeah hey patrice and we we've had various game developers on from Blizzard and Ubisoft Montreal. Yeah. Yeah, but as far as actual discussing graphics, I can only think of a couple.

I mean, we've had lots of people who use graphics programming, but then actually discussing that topic. Right. Okay, we'll have to come up with a couple ideas, and we'll get back to you, Drew. We'd love to hear your thoughts about the show as well. You can always reach out to us on Facebook, Twitter, or email us at feedback at cppcast.com. And don't forget to leave us a review on iTunes. Joining us today, just heard him, Patrice Roy. Patrice has been playing with C++ either professionally for pleasure or 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 of 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. Patrice, welcome to the show. Hi there. That's a full house, it sounds like. Yeah. Yeah, well, the kids are spread from age 22 to 4, so the eldest two are gone now, but we see them very often. And the cats thing is because we have a refuge at home, so we have between 15 and 25 cats all the time.

Oh, wow. Some of them are ours, but most of them we find homes for. So we get them, they're abandoned, lost, sometimes hurt. We feed them, put them back into shape, and find families. That's a big responsibility. Well, my wife works with animals. She works at the veterinarian's

clinic, and it's her passion. I just do the litter boxes. That's potentially a lot of litter boxes with that many cats. There's four big ones, yeah. And then we do them every day. Wow. So I'm curious, your C++ time started before mine.

What would you say is the most significant change that's happened since you started programming in C++? You just said I'm old now. That's what I heard. No, no, no. I actually, well, okay, so to be fair, my first non-professional experience with C++ was in 1995, but I didn't really know anything then.

So 2001 is when I would say my real C++ experience started. I did a lot of C and Fortran before, too, so I've been doing C++ for a long while, but I had a hiatus of a few years when I did Flight Simps, because in the Flight Simulator world, when I was there, they were scared about even things such as local variables, because they involved stack movement, and it was hard real-time stuff,

and they were scared it would take too much time to do pushes and pops. It was scary. But when I went back to C++, what's changed the most, I'd say, is it's become much easier to code cool, efficient stuff

with less typing and make it understandable. I mean, the code is becoming readable. Even for beginners, which is a very cool thing when you're a teacher. That's a good point yeah okay patrice well we got a couple news articles to go over and then we'll uh start digging into uh the recent c++ 17 meeting at kona that you attended okay yep okay so first up on that topic is uh herb sutter's trip report on the C++17 meeting, saying C++17 is complete and they've already started some progress on C++20.

Is there anything either of you wanted to highlight on the trip report here? Well, it's a good one, if I may. Herb works mostly at evolution. So we have four groups there, plus study groups. So Herb is mostly an Evolution guy. So, his report is tainted by this. And he gives a good overview

of the TS things, too. But there's a lot of other stuff going on in any WG21 meeting. But it's a good report. If you want to get a good overview of what happened there, well-written and everything, Herb's report is good. Another one that's very good, if you want to take a look at it, is

Botton Ballos. I could send you the link. He also spends a lot of time at Evolution. It's very complete and very well thought of. So, if you don't mind, could you explain to us what the different working groups are? Yeah. Evolution is the big room, normally. In Kona, it's a big, open

area room where you can actually feel the wind. It's the only place where you can actually breathe in Kona. We's a big open area room where you can actually feel the wind. It's the only place where you can actually breathe in Kona. We're all in closed rooms with conditioned air for the other part. So in that big room where we can probably sit everyone if we make an effort, they discuss where the language is going. So the new things are being discussed at a high level. It's also probably the roughest audience that you have there.

If you want to get tomatoes thrown at you, go there and pick them up. They work very well. The other working groups are libraries, who work a lot these days. During Kona, they were the most occupied group because they had a lot of stuff to fix for C++17. So these guys are your current heroes right now. You have LEWG for the evolution of the library where the new things that

might be added to the library are studied, discussed, and eventually voted in. We discuss namings there when we meet and everything. And there's Core where I spend most of my time where we work on the actual wording of the language and the

rules that make the language work. It's a very abstract place. All of the four groups have very different ambience. Evolution, it's open ground. It's kind of like in ancient Greece where you go up and people

scream at you if you're not okay, except it's more civil. Library, it's working class stuff. You're sitting down, working, fixing bugs. It's very important work. Marshall does a great job there. You've had him a few episodes ago, if I remember.

LEWG people sit down, they split the work in subgroups, discuss things in subgroups, and then come back all together to make common positions. And core is more like a strange church thing. When we're all sitting down, there's not much noise, and everything everyone says is scary. I really love that. All the examples that come up are written by people who see the worst in us

so really it's where you see the worst code and your mind wanders and says damn people thought of that it's an amazing place to work I'm going to put you on the spot do you have an example of what these scary examples would be?

there are ways to return the address of variables that don't exist technically speaking yet in C++ program right now using auto-declaration type and the new features that we have. You look at the code, it works. There's something going on in each compiler.

You're wondering if it actually makes sense to allow it. I could type it for you, but it wouldn't make for good radio. You'd be astonished to see what people come up to try to make the language fail. It's amazing. Out of curiosity, is this something that the compiler is worn on? Well, sometimes we wonder if we should actually make sense out of those statements, or if it's just a hole in the system.

And if it makes sense, what sense does it make? It's a scary place where we wonder about those things. We have something for C++20 coming by Louis Dion about lambdas in unevaluated contexts. There are places where you can use, you will probably be able to use lambdas in C++20 that are useful for some techniques that you cannot use them right now. But when you start using lambdas that are distinct from one another, even if they're written the same way all the time,

it just makes you wonder about how HODR works anymore because there are all those weird questions that come up in core that just make your mind hurt. It's very pleasurable if you're into that sort of stuff. And you have all the study groups. There's four things, so it's all different.

I'm curious, you mentioned these four different personalities. Do each of the working groups do you think they attract people with that personality? Or do you think people come in and then, okay. There's both. So there's the, in French we'd say les habitués. Those are mostly sitting in the same group all the time. We all have our habits and our preferences.

And some people move about, you know, because they want to get a feel of each. Or there's a discussion that really interests some people, so they really want to go there. Sometimes we have joint sessions. We discuss concepts with core and evolution together for a whole day in Kona because we have things to fix that involve both evolutionary concerns and wording concerns, and we have to discuss them together. So that happens too. And there's people who just move. They are sitting mostly somewhere

but we all have proposals that go through each of the four groups. Everyone has to move about from time to time. One more thing I wanted to call out in Herb's post here is he mentions his comparisons proposal and how it did well in the Library Evolution Working Group. It was very well written.

What is the comparisons proposal? Could you summarize it? Yeah, I can. As you might know, there's been a lot of effort in the last few meetings to generate the relational operators for you on some basis. So let's say that you have something like tuples. You know, tuples, tuples? When you compare

them with equal equal, well, there's a default behavior that will be generated that does lexicographical compare for you, essentially. So we are trying to expand that for the rest of the language. But there's a number of interesting issues that come up when you do that, such as, are you actually generating the functions? If so, can you take their address? How does it mingle with the rest of the system? Does it affect the ABI's? Some of the proposals have tried to avoid that. Some of them have

involved inheritance in some way. There have been a number of techniques tried to achieve that goal. And one of the three key things is, do we generate them by default and you opt out if you don't want it? Or do we generate them if you want them by opting in, like equals default or something? Yes, so Herb's proposal is interesting in the sense that it's a very different approach. It adds a new pre-turtle language, the spaceship operator, so less than equal greater than.

And that thing does what we call three-way comparisons. So it returns an integral value that is either negative, zero, or positive. Like a style string compare. Exactly. So you can generalize through that single one all of the six others. So if we make that work, and I've been one of the

reviewers on the paper, I really like it. It's interesting. It's well written. It's well presented. If someone wants to write a paper, it's a good paper to use as an example. It brings the problem clearly up front. It says what it's there good paper to use as an example. It brings the problem clearly up front. It says what it's there for. It talks about prior art. It's really well written.

Herb did a good job. So once you have that one, if you write this, we can synthesize the other six from it. So we could teach people to write one operator, and you get all six for free. I feel like one of the questions that would come up would be efficiency concerns,

because doing a specific less than is probably more efficient, maybe more efficient than doing a generic? I think we could prove, if we make an effort, that we can make this one as efficient as we need. But it's not something I have proven, but it's a feeling that I get. The demonstration that Herb has done with this and a few new features like constexpr if and everything

seems to indicate that it could be as efficient as possible. Okay. Next article we have is the SEI CERT C++ coding standard release, and Software Engineering Institute makes this available. And I think we may have discussed this last week, actually, Jason,

with Robert. I feel like we talked about coding standards or the SEI book with him when we were talking about engineering. Right. Yeah, so it's a good resource that they're putting out there uh the secure coding standard um is this i'm not sure if it's a new thing that they've released this publicly or if it was released as a book previously but they're saying um you know due to you know user demand they've decided to release this as a pdf did you download it i have not downloaded it yet i was going to after this and take PDF. Did you download it? I have not downloaded it yet.

I was going to after this and take a look at it. Have you? I did. Have you, Patrice? No, I'm aware of that effort. I haven't read it yet. Any standard that's published is a good thing because you can use it to think, compare.

Some of them are really bad. Some of them are not that bad. The only thing I'm always scared about with those things is that people will take that as religion, saying they said that, so it has to be good, instead of thinking about it and saying, okay, what do I like about this? What's good about it? As long as people take some perspective on it, I'm okay. Okay. What were your thoughts on it, Jason? So, first of all, you have to register to download it.

And I could not get the CAPTCHA right. I had to actually go into the JavaScript and figure out what the CAPTCHA was from it. But that's beside the point. It's an extraordinarily reasonable coding standards document. I was afraid when I downloaded it. But all the things that are in here are things that I hope that all of us who are following best practices kind of things are doing anyhow. Like, don't use set jump and long jump.

And use valid iterator ranges. Don't define C-style variadic functions. I have to recommend this. And it mentions in the article that it's containing guidance for newer features like lambda objects. Did you find that? Like it is kind of modern C++ standards?

A lambda object must not outlive any of its reference captured objects. No, that makes sense. It's extremely reasonable. I think people should download it and flip through it. That's very good news to me. I'm glad to hear that.

Yeah, I was very surprised. It's one of those times that I actually hear a proposal for a C++ coding standard that doesn't sound like a C coding standard with classes taped on it. Right. And they do have a separate C coding standard, but it's nice to know that they're separate. Okay. Next is the 2017 program

for CPP Now was announced and full schedule is now online, although there look like there are a couple spots that are still listed as TBA. I guess those are keynotes that they kind of want to keep

as some surprises. I believe that's the case. Although they've announced one of them, haven't they? They announced the Rust keynote, I believe. Yes, they did. I don't see that on here, but yeah. They do seem to have all the keynotes still as TBIs.

Yeah. Now, Jason, I know you're going and you have some talks here. Patrice, are you going to be attending C++ now? I would love it. Every year people push me, you should come. The problem is it doesn't fit well with the exam schedule and I'm a teacher. So I have the same problem with meeting C++. It just falls during a period where it's hard for a teacher to get away.

So CppCon is better for me. It fits better with my schedule. That's a good point. I know that they fit it around Mother's Day, but I never thought about exam schedule. At university, it's okay, but I also teach in college where they end

a bit later and just crams at the same moment. But it really looks like a great conference. I skimmed through the proposals, including some guy who says Conexpr all the things. It's a ridiculous statement to make. There's a number of really cool stuff. There's one about system error.

It seems very simple, but I haven't seen that many good usage of system error, and I'm sure it's an underestimated feature. So I would have liked to go there. Anyway. Yeah, and I believe, if I know who's giving this talk, it is probably promised to be, yes, it's Charlie Bay. It promises to be quite entertaining, I'm sure.

I'm sure you'll tell us about it. It's being recorded, isn't it? Yes, and it's the first year that they'll have professional recording. So it should be out much faster than previous years. Awesome. And Jason, are there any other talks you wanted to highlight aside from your own in this i you know i honestly haven't gone through it all yet and built my own schedule i'm actually more focused on making sure i have talks to present i make sense but i really do need to do that and there's definitely some stuff that, uh, that looks good. And a lot of past guests that we've had and people that we interact with a lot on Twitter

and stuff are on here. It looks like they have three tracks, I believe. Oh yeah. That's normal. Yes. We have, uh, there's three main rooms that they present on. Okay. Okay. Well, Patrice, uh, we already talked a little bit about, uh, C plus++17 meeting in Kona with Herb Sutter. What were some other changes, big changes that happened at this meeting? Well, you're probably aware that we weren't going to introduce new features at that meeting because the goal was to ship the thing. And to ship the thing, we have to fix the ENB comments and make sure that all the national bodies agree with the actual document we're going to propose.

So it was a very hardworking, very intense meeting, but mostly bug fixes. There's a few features that affect the language in interesting ways. Deduction guides are interesting. If you're not aware, you probably heard about that, but deduction guides are a way to alleviate the task of writing generic code by removing the make functions in a way. So you can have a pair P braces 2, 3.5, which will give you a pair int double,

even if you don't write int double yourself, because we'll have a way to deduce the type from the arguments passed to the constructor now. But there's all sorts of things when you're trying to insert that into the standard library and make it work that come to mind, like how do you manage the allocators? How do you manage the unique pointer with the deleters and everything?

So as the author of the proposal was experimenting, he found that a majority of the cases went without a hitch. But there was still a 30% to 40% that needed some work and fixes and everything. So we keep on discovering interesting things with that. So features that change the way you write your code, they require experimentation, definitely. There was another feature that came up last week that's escaping...

There's a scope lock that is coming that you will be able to use to replace a number of lock guards that adopt locks. So right now, if you have many mutexes to hold in the same function, you will lock them

with std lock, probably to avoid deadlocks if you can, and then make them adopted by lock guards afterwards, such that they can be freed automatically when you exit your scope. There was a proposal to make lock guard variadic to simplify things. It caused ABI problems to change the way the type was made, so they did a new type called scoped lock. Scoped lock takes a number of locks and logs them all in an ordered way and then frees them at the end and everything.

But if you're trying to mix that with adoption, the deduction guides behave strangely right now. So there's a number of, when you apply the thing, you discover things. So we did work on that a lot. File system is immense work. So Beam and DAWs did great stuff. But Library has been working on file system, day in, day out, all week long. So yes, this sort of stuff has made the meeting interesting.

It seems you just mentioned file system. It seems I saw some tweets about fixes that were made in file system for C++17, but I don't know, Are you aware of any of what they needed to fix? I don't have all the details. Okay. The file system as it exists in Boost works very well for POSIX systems. Okay. But now we're going to have something that works well with Windows too,

and we're discovering things all the time with the way that the slashes and backslashes interact. Dot-dot directories, when you have many of them, what does it mean? The meaning we give to the dot as a header to a file name instead of a trailing thing. It's a common practice in Unix to treat that as a hidden file. In Windows, it's much more rare. So the idioms and practices, the naming, there was a lot of small things there for such a mature feature

because if you think of it, file system has existed for a long while. But turning it into a standard feature has proven to be more work than expected, for some of us at least. But it's going to be a cool feature. We need that. I mean, we're glad to have that thing, but it's a lot of work. So you're

in the core working group, right? Mostly. So was there any surprises that came up in Kona that you're like, uh-oh, we have to fix this for C++17? From a core perspective? There's, well... It's a funny question because the...

Yes, core work is always surprising. There's nothing else than surprises during the week when you're sitting in that room. What you get when you're in core is people coming in with features that have passed the test of other groups. And then they come in and they have words. And then we work on the words and hack it and everything. And it probably doesn't work the first time. But you get people that you didn't expect all the time because they're being processed through the pipeline

and then the wording has to be applied at some point. We did a lot of modules work. And again, when you're writing the text for the modules TS, you discover things that seem okay from afar but need work when you look at them closely. A lot of people are wondering why modules haven't been adopted yet. far but need work when you look at them closely. A lot of people are wondering why modules haven't been adopted yet. Everyone needs

that. We know we want it. It's going to make our life so much cooler and solve all those problems, but the way it's written right now, we're going to have implementation divergences because the specs are not precise enough and they're hard to implement if you're not the person who has written the specs. And working together with the modules people, the compiler people, Evolution,

we're going to make that thing work because everyone needs it when we can make it work. But those meetings are surprising all the time. We keep on discovering ways in which ADL interacts, namespaces, modules, header files. We keep on being able to write examples we don't know what to make of, how to interpret the rules of ADL in the context of modules, what is being exported, understood by another module. If A exports this and B imports A and C imports B, what does C see from A? Transitivity of

importation. You can see the thing. So modules have been surprising. It's taken at least a day. Concepts have been surprising because we had a paper saying we need concepts and we need them today in that way. Another big paper that says, well, we need concepts and we need them today in that way. Another big

paper that says, well, we need concepts but there's this, this, this, that to fix and there's all those questions that need to be answered. Things like equivalence and functional equivalence. Traditionally, concepts are the same if they're expressed with

the same sequence of tokens. So A and B and B and A are not the same if they're expressed with the same sequence of tokens. So A and B and B and A are not the same concept necessarily. Okay. Exploring the ways in which concepts match or don't based on that is a very complex thing. It can explode in some ways exponentially because you end up with very complex graphs to explore to see if your function matches this or that concept

and if it's ambiguous or not. We had more than a day of work just on that with a lot of people. I hope people understand how much work goes into that standard. It's crazy to see how much effort is required to put something of quality on there.

It sounds almost a little terrifying to me, honestly. Well, we need the features. Everyone wants concepts, and everyone wants modules, and they're very, very important things to us. So if you're talking about surprises, well, I didn't come there and expect to be sitting in a big room with 80 people

trying to understand where we're bringing concepts to for the rest of the week. Modules, as I said. And there's also a number of small things that pop up all the time. Like there's issues that have not been fixed in core

since the beginning. Things that we keep on pushing back because there's more important stuff to do. Sometimes we try to bring them back and say, could we fix that now? Sometimes we can't. You have to give an example if you can.

Yeah, subtract. I'm trying to remember a specific example that I could put for you guys up front. And if you give me a second, I'll look into my notes because I wasn't ready for this. Well, if you say that there's a core language issues that have existed since the beginning that you haven't fixed yet come on that's too good of a teaser

you can actually go and look the core issues list is public the core issues have numbers and core issue 2 still exists. Wow. And I won't tell you whose name is assigned to it,

because it's still working with us, and it's a joke, because it's not his fault. It's just that the priorities of things make it so some things never pop up to the surface, and we just cannot make them. We always try to make them, but we can't. Oh, yeah. If you're wondering about the kind of surprising things pop up to the surface, and we just cannot make them. We always try to make them, but we can't. Oh, yeah.

If you're wondering about the kind of surprising things that we have to work on, there's Launder. Have you heard about that function, std launder? No. I have heard about it, but please explain it. Well, explain. The compiler writers sometimes want to, when you have an object, you have a pointer to that object, you destroy the thing, reconstruct on top of it something of the same type, say, is the old pointer to the old area of memory still valid if you use it,

even though you've destroyed something and replaced it by something else on top of it. It seems like people do that. When the compiler people are analyzing what you did and trying to figure out what they can optimize or not, sometimes they need hints, saying, okay, that made sense, believe me. Look away or do something.

We have this weird function named launder that lets you inform the compiler that, yeah, something happened there. Believe me, it's not a reinterpret cast. It's like, look away, I'm doing something dirty and I'll come back. The thing has impacts for library. It's required to write the correct vector, among other things. But we're trying to define the contours of where

we should apply that thing to make the language sound and solid. Because some things just work sometimes, but if you look at them underneath, they shouldn't be working. And we want a language that's sound and working, so it's a lot of difficult work. Core is abstract, I'm sorry.

So you were talking about spending a lot of time on concepts and modules, which are obviously going to be for C++20. And there's still TSs. At what point or what is the process for them to go from a TS to actually becoming a feature that we think will be a part of C++20? Traditionally, we haven't been good at that. Most of the TSs that we have are not implemented by all the compilers, but we're hoping that some of them will implement them all soon.

My feeling is that we have a good chance of the big things like coroutines, modules, concepts, being all implemented by at least one vendor by the end of 2017, that's my feeling. That would be a good thing because we'll be able to actually use them. Right now, if you want to experiment with all three features, it's hard to find a compiler that will let you do that because none of them actually do them all. We have had a discussion in Kona because we want to make... People are scared of TSs because they're not as available as we would like them to be.

So we want to bring them to the main trunk as fast as we can. So my feeling is that we should start merging TSs much faster into the main IS, the main standard, starting like 2017. So expect concepts to

merge in faster than expected. Expect modules to merge in faster than expected. I don't know if it's going to be in Toronto, maybe in Albuquerque in November, but we'll start merging them soon. So these things that are testing rounds right now for ideas, as long as we've got something working

for at least two compilers, my feeling is that we're going to start merging. On that topic, do you think the TS model will continue to be used, or are you trying to move away from it? I don't know. It's a good idea if people implement it. So if we see compilers implementing that thing faster,

I'd say such that people can actually play with it. It's going to be a good model and we can keep it up. If it doesn't, I don't know where we're going to go with that. So there's people who are strong believers in that, people who complain about the process. I haven't been there long enough to have good perspective on it, but my feeling is that if we merge them soon, we'll be able to say, okay, it's been helpful.

We've been playing with it, people have used it, and we have enough experience to know where we're going with it. So, yeah, it could be a good thing. It does seem like it would have to be valuable that these big core language things have some implementation that people have tried. Yeah. Well, we have modules in Clang and

MSDC. They're different, but they are essentially the same, but you have to make some tweaks to make them work. We have concepts in GCC. I don't think we have them in Clang yet. We have coroutines in MSDC and Clang. So we are getting there.

If you have at least two competing implementations, you can actually make headway. When there's only one, it's tricky. Yeah. I wanted to interrupt this discussion for just a moment to bring you a word from our sponsors. IncrediBuild dramatically reduces compilation and development times

with unique process virtualization technology. The tech transforms your computer network into a virtual supercomputer and lets each workstation use hundreds of vital cores across the network. Use CrediBuild to accelerate much more than just C++ compilations. Speed up your unit tests, run more development cycles, and scale your development to the cloud to unleash unreal speeds. Join more than 100,000 users to save hundreds of monthly developer hours using existing hardware.

Incredibles is already integrated into Visual Studio 2017. Just make sure to check the Incredibles box in the C++ workload in the Visual Studio 2017 setup. So one new feature that did come out of C++17 Kona that we didn't talk about yet was std byte. Do you want to tell us a little bit about the work for that? You've heard about that.

Okay. So for those who aren't aware of this, this is not abstract at all. We want to use char for characters. Crazy concept. So right now char is everything and it makes optimizers weaker than they should be.

We could do a better job. So the actual concept of using char as a corrector may seem very strange to C and C++ programmers, but it actually makes sense to most of the people who code in other languages. To remove the

responsibility of char to LDS everything right now as a byte, to remove the responsibility of char to alias everything right now as a byte, well, we're trying to have an actual byte type now, if you look at the way history has brought the language where it is byte types abound

people do typedefs people do macros, and they replace byte by char on sign char or something. Uint8t, whatever. But all of these types, because that's the way the language has been made so far, not being classes, being just aliases, you can do arithmetic on it.

You can do plus plus, plus equals, whatever. The stdbyte type is not meant to be an arithmetic type. It's meant to be a thing to alias storage. So one of the big questions was, okay, so does it map std byte to the bytes

that we know? And people were divided on that because some people said, well, the byte types that we have right now, they're doing arithmetic, which is weird. And if we implement arithmetic on it, do we want the full blast thing or just the bit masks or something? What do we want to do with a byte? So there was some concern about the name due to that because people were wondering if byte was the good name for this thing as traditional byte types for historical reasons and other behavior. That blocked the feature for a while,

but I think we're all mostly comfortable now with the fact that we picked byte as a name and it's going forward. But there's still some things to fix with it, because the boundaries of what the type is allowed to do are unclear, like bitmaps and everything. Where do we go with that? But essentially, we will have a byte type that aliases memory,

which should allow us slowly to move char back or away from its traditional role of being a byte and putting it back into being a char. It's going to take a while. It's going to take at least two is's.

Right now, char has special wording, if I'm correct, in reinterpret cast, I believe, or static cast, because like you're saying, it's an alias for a memory pointer. So do you expect that to go away and be replaced with byte? Well, that's a long-term goal. But we're talking long-term. It's a slow thing. The

tradition of C is built on that thing. The interactions between C and C++ rely on that. The whole C library relies on that. So it's a slow, moving away thing. But it's a good thing as long as we take our time and do it right. Because using

char as a byte is an obstacle for optimization. It aliases too many things right now, and it's hard to reason about the limits of that thing. If we end up making transition properly in 10 years, maybe your C++ code will be faster than it is today for all those level things. So you think this will ultimately be able to address these problems that some people have with strict aliasing rules where they're pulling things off the wire and casting them to structs and that kind of thing?

I'm not sure we're going to fix that problem. That's trickier. Things like taking a chunk of memory and saying with a cast, this is a struct, and using it as a struct, it's not actually legal C++. Right. That doesn't mean it doesn't get done. It gets done. I do that all the time.

It makes networking problematic in some ways. Anyway, so byte is not going to solve everything, but it will move char to a more reasonable space. If Fittner operating with C is a big concern with Byte, has there been any talks with the C community about changing this on their end as well? I don't know how the interaction will go.

We have a number of people who sit on both committees, but the CWSS committee is much, much, much bigger than the C committee. And interaction with C, at least in core, it comes up all the time for those things because it's very important for the low-level way that things are being implemented. We care about that. So how will the migration occur?

And how will we collaborate with that? I don't know, but it's going to be done. We're at least going to talk about it. Okay. I don't think we're going to throw C out of the window in the short term. It's not how we see things. So is byte defined as 8-bits then on all platforms? My memory of it is yes,

but I don't have the proposal close to me right now, so I'm sorry. I don't want to commit myself to this one. I know that was one of the things that Herb was tweeting polls about, like how big is a byte kind of thing leading up to the meeting. It's because the perspective that Herb has, and I can understand that, is that we shouldn't be discussing naming in big groups unless there's a very big reason to. So we shouldn't, that's not the place where we should be discussing that thing.

And on the other hand, if you think about the people working in the smaller groups, when they are discussing an issue in a group, you don't always know about it because you're doing something else. You're trying to go to things that interest you, but sometimes there's just too much going on at the same time. We're all working like around the clock. These meetings are crazy. You're like up very early, you go down very late in the evening and you work all the time. I've been on the highway twice so far. I haven't touched the water once. And so you miss stuff. You can't help

but missing stuff. So sometimes it's when you come up in planarine, you vote that you learn about things. So we're trying to ensure that planarine is not the place where we discuss technical issues like names, but sometimes that's where you'll get the opposition, because that's where you hear about it and you're like,

what's going on? But Herb wants planarines to go smoother, and I can understand that is the convener. Right. So we've talked about a couple minor issues that are still being worked on for C++17 for it to be fully complete. How much exactly is left to be done, and when do you think it will be kind of set in stone? Well, the draft IS is done. You can read

it right now. It's available on the C++ mailings, and for it to be adopted, it has to be accepted by all national bodies, really. So we're going to get some feedback from the national bodies in Toronto,

work on it, and unless there's strong opposition to anything, my feeling is that in November it's going to be official. Okay. You should know what C++17 is. Technically speaking, we've already forked C++20. So we are working on C++20 starting now

and fixing bugs in C++17 if there's anything that comes up. So one of the changes that was C++ 17 that was made at Kona that stuck out to me, and you can correct me, but this sounds right up your alley for being on the core group, is that the wording,

the name was changed from decomposition declaration to structured binding declaration. And I've seen both of those terms go back and forth since structured bindings were created for C++ 17. binding declaration. And I've seen both of those terms go back and forth since structured bindings were created for C++17. What was the argument there? It's actually very interesting because you're at the

frontier between evolution and core with this one. Okay. So there's two concepts. They're not technical concepts. I mean, not the word concept in the language, the idea of concept. Right. There's the decomposition of the return type, and its binding to actual variables. Okay.

Okay. So in terms of core wordings, we need two things. They were being called decomposition declarations in one hand, and structured bindings on the other hand. The reaction from the evolution people was that decomposition declaration would pose problem because people will see that in the error messages when they compile

their code. And they won't know conceptually what to map that error message to. I'm doing structured bindings, so what that decomposition stuff, what does it represent? Doesn't make sense to me. That's what I read in the books. So they were pushing for the name-structured

bindings to be used all over the place because people will know what we're talking about. Now the problem is that we can't use a single word because there's actually two things going on. So the argument by the core group was, well, we still need two things there because conceptually

speaking, there's a mechanic that decomposes and there's the binding that's the result. So what we ended up with as a compromise that I think works is you'll get structured bindings declarations, which is the decomposition process, and structured bindings that are the result. Given that, when you have an error message, the error message will talk about structured bindings.

And if you've read a C++ book recently, you'll know what it is. All right. So we're trying to take care of users. Makes sense. I think that makes sense, yeah. Although maybe we should, I don't know if all of our listeners are clear

with what structured bindings and decomposition is, but I don't know. Let's take two seconds because it's very easy when you've seen it. It's actually beautiful. You map that with one thing that Thomas Coppe did, which is allowing you to

declare variables in an if statement say. So you do if and then you do normally, let's say you take a function that returns a pair that has a Boolean that says, hey, it worked, and an actual result. So normally, you would take the result, which is a pair, and then check your result first to see if the Boolean was okay, and then use the result.second, which is the actual result that you got. And you could, like, if you don't have exceptions, you can have an alternative to exceptions with this. It would look kind of like the Go language where your functions return many things, and you can, like, take them as different variables.

Now, you can say if, parenthesis, and then you put an open bracket. And you say, let's say, OK, OK, comma, res, close bracket. So you have two variables there, OK and res, OK being the Boolean and res being the result, equals your function. So your function returns a pair. It's being decomposed into two different things named as OK and res. And then you can do semicolon and test OK as the status of the thing. And inside the statement, use the res thing. So instead of getting a pair,

you're getting two distinct variables that are created there. And if you map that with the new if statements, well, your variables, they only live in the if statements, so they are scoped for the if, which is very cool, the if and the else that's associated with it. So you actually end up with very clean code, very local variables. It's a beautiful way to code.

And as you said, NowC++ is actually becoming more readable. Yeah, yeah, it looks cool. This lets people who don't like exceptions write clean, clean code that relies on other things than exceptions to test the result of their function without declaring variables all over the place. It's concise, it's precise, it's readable, and it's well-scoped. I think C++17 will be a beautiful language to code in. I'm looking forward to it. I've spent enough time playing with C++17

that now when I have to go do real work, I'm like, man, I'm missing so many features. Yeah, I understand that. There's been people complaining about C++17 being not as major as they think. It's a major language. It's a major thing. The big features we wanted are not there, but there's a host of interesting

things in there. The more I go, and the more I see C++17 as programmer candy, really. You're a programmer, you're going to love working with C++17. It's a lovely language to code in, and yes, the big features are going to be coming in three years. So what?

We're going to get them at some point, but you're going to enjoy C++17. It's going to make your life more pleasant. It's going to make your code faster, cleaner. It's going to be fun. Sounds great to me. Yeah. So, Patrice, I know you've listened to several episodes before. I'm wondering if you had a chance to listen to

our interview with Robert Ramey last week yet. It's in my to-listen list because I haven't had to travel recently. I traveled last month, but your podcast is more recent. What I love with CVPcast is that I bring it along with me when I go on a

plane trip, so it accompanies me all the time. That being said, I know what you're going to talk about. You're going to talk about the Boost ASIO thing. Yeah, so he was talking about Boost ASIO and how things like those TSs, these very large complex features that currently exist as Boost libraries, maybe don't make so much sense for standardization. And we kind of wanted to know what your thoughts were on something like that as a member of the standards committee. Yeah, and as a programmer too. I've done distributed systems for most of my life now.

I always feel a bit ashamed when I have to give a class to some people and I need to go to the C sockets API to make that work. And I have to show unions, because that's the way the C API is done, because it goes back to the 70s. And I have to do reinterpret casts. And I have to do all of those early tricks.

I can teach it. It's okay. It's part of my job. It's interesting to teach that thing, but we shouldn't have to go there when we're doing C++ code. So regardless of the complexity of Boost.ACO, we really need that thing. We're going to find a way to teach that.

We're going to write books about it. We're going to give classes. That's okay. And people are going to write much cleaner code with it. It is a big beast. Like, file system is a big beast. You don't sit down and learn file system in a day. You have to play with it and get like get comfortable with it but it's it's really a shame that we haven't had

that yet we really need that feature so you've mentioned several times that you're a teacher and i'm wondering with the way you just introduced this uh there were talked about boost asio is like do you think networking is kind of like the last frontier of where we have to write ugly C++ and once we can get past that? It's the one I get into contact the most. It so happens that in my life I do parallel and concurrent stuff, I do real-time stuff, and I do distributed systems.

That's what I've been doing for the last 20-25 years. So the low-level API with which I'm always dirtying my hands is the Sockets API. And I don't mind. I mean, it's okay. Sockets are cool. But the number of things that you have to know to use Sockets,

man, that are non-C++ idiomatic. Yeah, you have your book in your hand right now. It's teachable. It's okay. But it brings us back to another era, really. So moving the concepts a bit

higher up and making people able to program in C++ rather than in C when they're doing their networking APIs, I can tell you how happy I am about that. Think about threading. The first time I could write include thread, I felt so good.

And include chrono, because all of those sleep functions vary from OS to OS. Now you can actually use a portable way to represent the time you want to wait or something. So these are big upgrades. They're not perfect. When you're using threading, sometimes you have to go lower.

But for day-to-day jobs, you can actually do include thread and write lambdas and it works. Damn, that feels good. Okay, well, Patrice, I want to know where can people find you online so they can follow more of your stuff, maybe look at your presentations coming up?

Yeah, well, I will add that I have a significantly large website with very weird colors. Because my perception of colors is disputable. But it's mostly in French. But if people want to look at it, I know some people,

sometimes they use Google Translate with my stuff to look at it. The code is code. So I'll send you a link for that. And I have a Twitter account that's my name. So M%PatriceRoy1. And why is it such

a boring, bland name? Well, I'm not a social network guy, so I don't have a Facebook account really or anything. But sometimes at some point I had a push from the university saying, you should be on Twitter to talk to people. So I just created a name there saying,

well, I'm just going to have some awkward, never-there presence, but I end up talking with people who are actually interesting. So I kept the account alive, but I have a bland, bland, bland name for it. Well, you're a good person to ping if we have questions about weirdness in the standard on Twitter also. Yeah, I'm sorry for the abstract talk today. I didn't expect it to share into the core stuff, but still. No, it's been great.

For those who want to go to meetings, you know it's open to everyone. It's an experience. The meeting report that you will see from the people who come there as observers, we had a few in Issaquah. The Microsoft MVP people who took the car and went to the meeting to assist for a few hours to see how it goes. Look at their reports. You'll see how interesting it is to see people coming from the outside and saying, oh, these guys are actually working all the time. People work. I'm seen as a workhorse, but I'm just a normal guy there. Everyone works all the time. People work. I'm seen as a workhorse,

but I'm just a normal guy there. Everyone works all the time. Everyone is very intelligent. Everyone is very nice. It's a very pleasant experience to be in. Okay. Well, thanks so much for your time today, Patrice. Thank you, guys.

Thanks for joining us. 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.