CppCast - Library Working Group and libc++

Episode Date: January 11, 2017

Rob and Jason are joined by Marshall Clow to talk about his role on the C++ Standards Committee's Library Working Group. Marshall is a long-time LLVM and Boost participant. He is a principal engineer at Qualcomm, Inc. in San Diego, and the code owner for libc++, the LLVM standard library implementation. He is also the chairman of the Library Working Group of the C++ standards committee. He is the author of the Boost.Algorithm library and maintains several other Boost libraries. News C++Now 2017 Call for Submissions 2017 European LLVM Developers Meeting Passing functions to functions A Tourist's Guide to the LLVM Source Code Marshall Clow @mclow Marshall's C++ Musings Links "libc++" C++ Standard Library Qualcomm The Committee: WG21 CppCon 2016: Marshall Clow "STL Algorithms - why you should use them, and how to write your own" CppCon 2015: Marshall Clow "string_view" Sponsor JetBrains

This episode of CppCast is sponsored by JetBrains, maker of excellent C++ developer tools including CLion, ReSharper for C++, and AppCode. Start your free evaluation today at jetbrains.com slash cppcast dash cpp. Episode 85 of CppCast with guest Marshall Clow recorded January 11th, 2017. In this episode, we talk about methods to pass functions to functions. Then we talk to Marshall Clow, chair of the library working group. Marshall talks to us about Lib C++, his 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?

All right, Rob. How about you? I'm doing good. You know, North Carolina is kind of crazy right now. As you may have heard, we were expected to get between 6 and 11 inches of snow. Oh, I didn't know it was going to be that much. It was supposed to be that much, and we got one inch with that. But because this is North Carolina, because it's the South, they can't handle any snow at all. Even though it's 50 degrees today and most of the snow has now melted away we still have no school because there are parts of the state that have not or parts of

our county that haven't fully plowed and not every kid could potentially get to school so we're still canceled well i know from living in virginia that area is like that with a lot of tree cover which we don't have in colorado you end up with like black ice on the back roads where the school buses need to drive on and stuff so maybe i guess but i mean yesterday it was melting off pretty well like i said it got up to close to 50 degrees yesterday i think and today even higher so there's really nothing left so i thinkolina's crazy anyway at the top of every episode like to read a piece of feedback uh this week or last week we had um we had britney friedman on and she kind of made this offhand remark about uh the c++ standards committees and how different uh countries will all get to send a voting representative and she mentioned czechoslovakia and uh several listeners pointed out that Czechoslovakia hasn't been a country in about 20 or so years

we looked at it, right? Yeah. Yeah. So Czechoslovakia. It's funny neither one of us got that. Thank you for everyone for pointing that out. It's kind of just an offhand comment, though. 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 cpcast.com. And don't forget to leave us a review on iTunes. Joining us today is Marshall Clow. Marshall is a long-time LLVM and Boost participant. He is Principal Engineer at Qualcomm Incorporated in San Diego and the Code Owner of LibC++,

the LLVM standard library implementation. He's also the Chairman of the Library Working Group of the C++ Standards Committee. He's the author of the Boost Algorithm Library and maintains several other Boost libraries. Marshall, welcome to the show. Thank you very much. I'm glad to be here. Yeah, thanks for joining us. You know, this is off topic and not directly related to your bio, but since you've been working with LLVM so long, there is the recent news that Chris Lattner is leaving the project. Does that affect you guys a lot?

We'll see. Chris has been, I mean, Chris was one of the people who started the LLVM project back at the University of Illinois, I believe it was. And then he was hired by Apple in 2006 to basically to push LLVM as Apple's preferred development tools. And then he's been leading that effort and leading the Swift stuff at Apple for years and years. And so I imagine this will affect those projects, but I don't know how much because he's been doing a lot of stuff with project management

and he's been doing some coding, but I don't know how much. I don't have any visibility into the Swift side of things because that's pretty internal to Apple. And on the LLVM side, he used to spend a lot of time working on the back ends and then the middle part of the compiler, which is not where I contribute. So I don't really know. We'll see.

Ted Kremasek is stepping up to keep doing the Swift stuff at Apple, and Ted is a really smart guy, so we'll see. It will be interesting to see Chris's on the LLVM Foundation board. It will be interesting to see if he keeps that job. Right. Okay, Marshall, we've got a couple news articles to go through. Please feel free to comment on any of these, and then we'll start talking to you more about the work you've been doing for years, okay?

Okay. Okay, so this first one is the C++ Now 2017 has put out their call for submissions. And it looks like the due date for submissions is February 3rd. Jason, you've been attending this conference for a while now. Are you going to be putting in a submission? Yeah, one or three, somewhere in there. But it's important to point out, so you just said February 3rd, this is one of the, I think, shortest submission windows they've ever had.

So if you have any thought of submitting a talk, get it in right now. Exactly. C++ Now is a very fun conference. It's a small conference. It's held in Aspen in May. And it started out as a Boost-specific conference. And it has widened its focus somewhat, but it's still very, very technical, very much about nuts and bolts of code.

The presentations tend to be more interactive than most places. I've been involved with this conference since the beginning. It's a lot of fun. It's a great place to present at, because like you said, it's interactive. It's guaranteed people will talk back at you and point out the flaws in your presentation, but in a good way oh yeah everybody is friendly but at the same time yeah you can't you can't kind of hand wave your way through the conference is also like i said it's very small we're limited by the venue to 150 people and yeah if you're not planning on presenting a paper, they just want to go

registration should open within a couple weeks. Yeah, I think the date is listed as well. Like I said, the proposal submissions are due February 3rd. Decisions will be sent out on the 27th and the program goes online on March 20th. I guess, does it not say when

registration opens up? I don't think it actually specified. Okay. But I'm guessing somewhere in the February to March time frame. I would be surprised if we make it to the 1st of February without opening registrations. I'm the registrar for the conference, so I'm surprised.

You should at least be aware, though, when it does go live, I'm guessing. Yeah. Yes. Well, I'll be the one that throws the switch to make it go live. Okay. And, Marshall, right before we went on the show, got on the call,

you mentioned that registration is opening up for the Spring LLVM Developers Conference? Yes. That just opened this morning, as a matter of fact. Okay. Every year, the LVM community holds two developer conferences. One in the spring, one in the fall. The one in the spring is traditionally in Europe,

and the one in the fall is traditionally in San Jose. So the spring one, they opened registration this morning. It's in Saarbrücken, Germany, which, if you look at a map, is basically the very western edge of Germany. There's a Saarbrücken, Germany, which if you look at a map is basically the very western edge of Germany. There's a little corner where Germany, France, and Luxembourg all come together. It's there. And it's

a two-day conference. It's relatively inexpensive for conferences. I believe it's 150 euros. Oh, yeah. And they have a call for presentations out as well. I'm curious, what kinds of things would you expect from the LLVM conference besides the obvious discussion about LLVM? Well, that's a lot of it. There will be discussions on techniques for improving LLVM. There will be presentations on how to improve, say, the code optimizer in LLVM or internal data structures for LLVM, there will be presentations on how to improve say, the code optimizer in LLVM or

internal data structures for LLVM, but there will also be a set of presentations of people using LLVM for things that aren't compilers. There will be people who are taking the LLVM libclang, for example, and using

it to parse source code and pull out metrics or to do analysis or things like that. Um, at the last one, there was a guy who was using it to, well, a couple of people who are using it to find copy and paste artifacts where basically somebody has picked up a chunk of code and,

um, pasted it into another file and included it in the source space and so you can say hey look this routine over here and this routine over here are the same sounds handy yeah yeah it's it's a computationally hard problem you know it's basically it's a graph matching problem pretty much, which can you can spend an awful lot of CPU power finding. Right. But yeah, it's basically

people doing things with LLVM and Clang or improving LLVM and Clang. Okay. This next one is an article on Vittorio Romeo's blog called Passing Functions to Functions. And he's kind of going over different techniques that you can use to pass one function into another function.

Function pointers, template parameters, std function, and function view, which he goes over an implementation of. What are your thoughts on this one, Jason? I had been pondering how one might do something like a function view. And when I saw his implementation of it, I was like, okay, that's pretty cool. It's not something I thought of. Although it makes me just a little nervous because it makes an assumption that the thing that you're doing a view of, like it doesn't take a copy of the thing that you're doing a view of, which obviously, I mean, it's a view, so it wouldn't, like a string view wouldn't. But I don't know, it just makes me slightly nervous about the lifetime of the function

pointer that you're using the view on because of the use case scenarios that he has. But otherwise, it's pretty cool. I don't know, I think Marshall might have an opinion on this since he has done things like string view and array view implementations. Yeah, this is, you know, Vittorio is a smart guy. And this is a nice little piece of code. It's, you know, the whole view discussion, I guess, is probably a good word to say about string view and array view and function view

is one that people are having on, you know, do we want to promulgate these collection of nominally unsafe tools? And I think the answer is going to come out as, yes, we do, because the performance wins are very big. But we'll see. I was amused by the fact that one of the first comments was, wow, this looks an awful lot like LLVM's function ref. Right.

And it is very much like LLVM's function ref. So there are a lot of interesting things in the LLVM code base, which might tie into some later discussion. But in any case, it's a nice piece of code, and if you can live with the limitations, like I said, the lifetime management things, which are the same as StringView, then you can get a really nice performance win. I'm not sure I completely agree with his conclusion about std function, which is basically never use std function. I think there are times where std function is a good thing. But yeah, it is he's right, it is a heavyweight solution. It's a very general kind of heavyweight solution.

And we have other tools like lambdas and FunctionView and things like that that do almost all of what Standard Function does in a much more performant manner. I think, in my opinion, Standard Function falls under the try really hard not to use it, not never use. Standard Bind is the never use, in my opinion. Standard bind was a godsend before we had lambdas. Yes.

And, well, boost bind, actually. That's where I started using bind. Right. And I'm interested in your thoughts on this next one. This is a Taurus guide to the LLVM source code. And this comes from

a guy named John Rigger. He says he's a professor of computer science and he was working on an advanced compilers course. And after going through that course where they looked through the LLVM code base, he decided to write up his own just kind of Taurus guide high-level view

of all the different parts of the LLVM code base. So what were your, your thoughts on this Marshall? Is this kind of useful? Is this accurate? It seems to be pretty accurate. Yeah. There's you know,

so he's yeah, John is, John is an interesting guy. He has done a lot of work on undefined behavior and priming errors in, in programs. And so this done a lot of work on undefined behavior and finding errors in programs. And so a lot of this stuff, there are a lot of things in LLVM that have been inspired by some of his work, like Undefined Behavior Sanitizer, which is a tool for finding undefined behaviors in your program. And so he is continuing in that work.

But this is just a very high level you know this is in general where things are and these are the kind of things that are here i mean this is a good place to get for people who get want to get started with the lvm code base you know after a couple hours you won't need this anymore because you will have discovered this all yourself. But it would probably save you a couple hours at the start. And as I said before, LLVM is not just a compiler. It's a large publicly available source code base with lots of useful things in there. People ask me every now and then why STD vector doesn't have a small object-oriented implementation. And there's a good reason for that.

You can't fulfill all the requirements in the standard with one of those, but with a vector that does that. But there's one of those in the LLVM code base, which you can lift out and use. So, yeah, there's lots of interesting things in there. They built a lot of containers and a lot of utilities that are useful outside of LLVM. I have definitely not spent any time digging around the LLVM code base myself. It looks large. It is very large. And you know,

a lot of the tools and a lot of the utilities they have are organized around manipulating source code or manipulating object code. But they're still really useful. They can be generalized or they can be used as is. Okay. Well, Marshall, from your bio, we can tell you obviously do a lot in the C++ community. Do you want to start off by talking about your role as library chair? Sure. So for those who are not aware, there are really five working groups in the C++ Standards Committee,

which goes by the unassuming name of WG21. But the five ones are core, evolution, library, library evolution, and concurrency. And basically, core and library are the ones that are responsible for what actually goes in the standard, the words that go in the standard, making sure that everything is consistent and correct. The library evolution and concurrency are responsible for designing or standardizing new features. This is a very high-level view, of course. There's a lot of back and forth. So, for example, if somebody were to propose a new library feature like, let's just say function view, since we were just talking about this, they would write a paper and it would go to the library evolution working group because it's a library feature. And the library evolution group would evaluate it, make some suggestions, maybe send it back to the proposer with, yeah, we like this a lot,

but you need to think about this and this and this. And eventually when Library Evolution is happy with it, they would approve it and send it on to the library group. The library group would then see if they have any concerns, but also look very carefully at the proposed wording, because the whole point of the standard is it's a specification. Okay, and so

people read this as to people read this to see what a particular piece of code is going to do. When you call vector clear say, you read the specifications, it's going to remove all the elements in the vector. At the end of it, the vector is empty. Great.

I mean, it's very, if you'll excuse the expression, it's very clear that that's what it does. And the whole point of the library working group is to make sure that those words are, say what is done in such a way that people reading them will know what happens and people who are implementing it know what to do. A lot of times what we have, you know, one of the things that we try really hard not to do is have two implementers go off and implement something and come back with different results. You know, if you take your code from Microsoft to GCC to Clang and, you know, you call a library function in all three of those, you expect it to do the same thing.

So, but the library working group, so the library working group is responsible for the words in the standard from the library part of the standard. And that's like a thousand pages. As the chair of the library working group, my job is basically is kind of mostly administrative to keep track of what's coming down the pike, what the group needs to discuss, manage the issues that come in from members of the committee and outside the committee, because people do report issues, aka bugk.a. bug reports against the standard, and say, this says this, but this says this, and those conflict,

and then we have to resolve them. And so I'm setting agendas and basically managing the group, just making sure that it always has plenty to do, which is not a problem, and that the right things get done. To do this, I have a lot of help because people who have their own standard library implementations tend to sit in the library working group. In the world today, there are four generally publicly available standard library implementations. There's libc++, of course, the one that's part of the LLVM project.

There's libstdc++, which is part of GCC. There's the Microsoft standard library implementation that ships with Visual Studio. And then there is Dinkumware's standard library. That's PJ Plougger's company that he develops and then he licenses to people. Okay. And there are various implementations internal to various companies. It's easy to forget.

I often forget about the Dinkumware one, but I have heard references to it before. Well, for a long time, the Dingamore library was the one that Microsoft used and about, oh, I don't know, last year sometime, early last year I think it was, that they forked it and went their own way. But PJ is a very smart

guy and he's been in the business a long long time um he told me once when we were sitting in a standards meeting that that this was the 50th anniversary of his first paid programming job and this was a few years ago let me see he got his first paid programming job in He said April of 1964. Wow. That's definitely a couple years longer than I have been. My response to that was, well, I was alive then.

So, regarding C++ 17, the next standards meeting is going to be in February. What's that meeting going to entail from your perspective? Are there going to be many changes. What's that meeting going to entail from your perspective? Are there going to be many changes made from the library working group? Well, so here's where we are in the standards process. In June, we voted out, we, the standards committee, voted out what's called a candidate draft, a CD.

And we sent this out to all the ISO members. Basically, this was, you can think of this as a beta release of the standard, of an upcoming standard. And we said, you know, so the response was, basically, here's what we're going to release. What do you think? And then basically all the participants read it and filed what are called national body comments. These are comments that come back through their various ISO representatives. So NB comments come back. You can think of them as bug reports against the beta standard. By ISO rules, we have to respond to every single one of those. We did some of that at the standards meeting in November, and we're hoping to finish these all up in February. And so if that happens, if we're able to resolve all of these, then in February

we will vote out what's called a DIS, a draft internet standard, and say, okay, we think we're done. And then the ISO management in, I think they're in Geneva, will basically send this out to all the member bodies with a ballot that says, do you vote to approve this? Do you vote to not approve this? And that vote to not approve this? And that balloting period will go on for several months. And if all goes well, sometime this coming summer, we will have

a new standard, new C++ standard, C++ 17. If we don't get it done in February, we'll have to do it at the next meeting which is in July and then the balloting period will probably slip over into past the end of the year and it will be a C++18

but we're trying really hard to avoid that so the library and the core groups the people responsible for the wording will be spending an awful lot of time working on wording, spending all their time working on wording. The evolution groups, library evolution and evolution, just plain evolution, which is really language evolution, but we never call it that, will probably be looking at things for post C++17. Hopefully there's not going to be any new features at all in C++17. It's a little late for that.

Yeah. But that's what will happen in February. We will tell everybody that we're sitting on the beach and having a great time because the meeting is in Kona in Hawaii, but really not so much. The first time I went to Kona, I sent my boss a picture saying with the caption, ha ha, I am in Hawaii and you're not. And the picture was a conference room with no windows with 80 people sitting in it, each with their own laptop. So there will be a lot of long hours in Kona. Hopefully we will get the DIS out,

and then people can say, yep, this is good, we should make it C++17. That's certainly the goal. So are there any bug fixes, I guess, from your perspective in the language draft for C++17 that you will be addressing in February? Oh, yeah. Okay. There are some things with structured bindings. There are some things with structured bindings and interactions between structured bindings and the standard library that definitely need to be fixed. There are also some things with the file system library

that just were not quite right. That's interesting. They need to be right. And it's much better since this will be the first standard which actually contains a file system library. It's much better to get them right when it goes out the door rather than enshrine not quite correct behavior and then users have to worry about,

well, am I using C++ 17 or some later version? And so on and so forth. I have to worry about different behavior. So the file system one just fascinates me because from my perspective, the file system library is extremely mature. It's been in Boost for as long as I can remember. I know it's gone through a couple of revisions in Boost.

So I'm just kind of curious. Can you give us an example of what you guys are addressing in the file system library? Well, there's a couple things. Well, the first thing is you've got to remember that the file source on the library in Boost is written all in C++03. Okay. Because, well, when Beeman started working on it, that was the language of choice. That was the only one that existed. Right. And so we need to think about things like R-value references and so on.

Are there places where passing a variable number of parameters improves the interface? So there's some of that. But also there were some people who were very, very vocal about the fact that the file system library as presented didn't really support relative paths. Everything was an absolute path. This was something that was on Beeman's radar as something to do for the Boost file system library. And so he did this for the proposal to the standard, and it's not as mature as the rest of the library.

People on the standards committee tend to be, especially the people in the core language group and the library language group, tend to be very, very picky because they're writing a specification. And it's really important to say, this is exactly what this call does. This is what this call does under this circumstance. This is what this call does in this circumstance. This is what it does in this circumstance. Because users depend on that behavior. And interestingly enough, when you try to write such a specification, sometimes this shows a hole in your thinking.

When you say, I know what I mean here, I just don't know how to say it. At which point you say, okay, then if I don't know how to say it, maybe my understanding is not as good as I thought it was. Makes sense, okay. I did a proposal for the library fundamentals TS that actually is going to be in C++17. These are the generic searching algorithms, or the generic searching framework, but the new searching algorithms, Boyer-Moore and Boyer-Moore-Herspool.

And in the original proposal, they were going to be part of C++14. But I struggled and struggled and struggled with writing the specification, writing the actual words to go with the standards. And finally I realized that as I was writing the specification, I struggled and struggled with a bit and finally realized that I was making an assumption there that was just not right, that didn't hold in some circumstances. And that's why I was having trouble writing the word, writing exactly what I meant. And I, so I ended up saying at the last minute, you know,

at a meeting while we were reviewing the wording, it's like, you know what? I think there's a problem here. And so I'm going to withdraw this for C++ 14 and we'll do it at a later date. And it turned out that, yeah, there was a problem there that led to some significant redesign. But it worked out. It's in C++17.

It's a better design. But sometimes getting the words right is really hard. We've had people go around and around like three or four times. Here, I wrote some wording, and people look, and no, that's not right because of this, this, this, and the person goes away and comes back. Frequently this happens to me. They'll come back three hours later.

Okay, I have new wording. No, it's still not right. So, yeah, the goal is to ship a DIS out of the Kona meeting. There will be, you know, people, that's the overriding goal. And then people, like I said, people in the evolution groups will be looking at post C++17 features. Because none of that's going to go into C++17. Right. Okay, so the evolution groups already moved on then. They're no longer looking at anything for C++17?

They're already working on C++20 stuff? Interesting. You think of writing a software project right you're you're in a late beta project late beta stage you know you've sent betas out people have looked at them you're you're finishing bug reports you're near the end of a project and somebody says here's this cool new feature yeah you don't want to accept that right now yeah you say you say go away yeah right although it did seem surprised surprising to me that in the last meeting um variatic using kind of snuck in yeah and yeah go ahead i agree that was kind of odd

so you don't anticipating anything like that happening in february i do not know although it does seem like it was kind of a hole, which someone I was chatting with on Slack, which, by the way, is a great place to talk about C++ stuff now, mentioned that we're missing variadic friend. And I guess that came up on Twitter also. Anyhow. The variadic using, although, that's proposed

doesn't actually do what I want, which is I want to be able to manipulate parameter packs and give them names. So if you have a template that takes a parameter pack, and we'll call it args because everybody does, I want to be able to say inside it, I want to say using args2 equals std decay args dot dot dot. Okay. Which I want to make a new parameter pack, which is decay applied to all the members of this parameter pack, and give that a name.

Right. You can't do that. That seems like the kind of bordering on the reflection and compile time manipulation kinds of things that some people are wanting also. But I mean, people have wanted reflection and compile time manipulation of types and so on for a long time. I mean, that was Andre's book from what, 2004? Modern C++ Design? Right. It was the first one that really just shoved that in everybody's faces. And people are still exploring that,

and now they're exploring it with variable arguments, variable number of arguments. But, yeah, parameter packs are still this kind of odd language feature. They're really useful, but they could be more useful. And I suspect that people will see proposals for C++ 17 to do more with them. So we noticed in C++ 17, we've gotten a lot of more constexpr support in the standard library, but it's still, I guess there's still functions that could be made constexpr.

I believe some of the algorithms that aren't currently, do you see that continuing to progress? Is that the kind of thing you need proposals on or is the library committee already working towards or? No, we definitely need proposals on them. I mean, nothing's going to happen in the standard without a proposal.

Okay. Right now, library implementers are in this kind of a weird position in that the standard gives them latitude, I guess is the word. I started to say levity, and I knew that was wrong. It gives them latitude to add noexcept to things that are not marked noexcept in the standard. And people do. But they do not have that same freedom to add constexpr, where the standard doesn't say constexpr.

And we're trying to get that fixed because then people can go off and, you know, standard library implementers can go off and add constexpr where they think it's important or where they think it's reasonable and then come back with a proposal that basically says, look, we've been shipping this for a year. This works just fine. And so we're working on that. But, yeah, there are going to be more proposals. You're going to see more constexpr,

more constexpr-enabled functions in the standard library. Chrono, interestingly enough, is now almost completely constexpr. The only call, I believe, in all of Chrono that is not constexpr. The only call I believe in all of chrono that is not constexpr is now. It seems reasonable. It reads the clock. But everything else, all the duration manipulation, all the time point stuff, is all constexpr. I had not seen that. Well, it was mostly constexpr and then at the last meeting you know

in response to a national body comment i might add uh we we made the rest of it constexpr uh just a second and i will tell you what the paper number is i believe it was 505 but Okay. Just a second. P zero five Oh five. R zero. I checked that out. Yeah. With the, with the amusing name wording for GB 50 GB 50 being a national body comment from great Britain.

Oh, okay. Um, but yeah, it's all, um, so everything in chrono is now constexpr, with the exception of now. Actually, there may be one other that converting to and from time t may not be constexpr.

Would that be a limitation because it comes from a c, part of the c library standard? I haven't looked at it real closely, but it may require some calls to c functions. Right. And, you know And C doesn't know anything about constexpr. That's kind of hard. You can't call C library functions at compile time.

Now, I know there's some interaction on some level between the C and the C++ standards committees, right? You guys try to normalize with each other occasionally. I had not thought about this before this moment, but it seems like constexpr is one of those things that it seems should translate to C fairly easily. Maybe I'm wrong. Probably wrong, really.

It depends on the calls, but yeah, there are some that definitely ought to happen. We have several members of the uh the c++ committee who also attend c c committee meetings who are c meetings unfortunately some of those people are retiring because they tend to be the people who have been part of the industry for a long long time right okay you know people like um you know pj ploggerer or Tom Plum or so on, who started with the C Committee and then started attending the C++ Committee as well. B. Mondoz, another one. So we'll see.

I haven't ever attended a C meeting, a C standards meeting, so I don't know exactly who is on that committee. We, the C++ committee, have a person whose one of his jobs is the C committee liaison. But that's an interesting idea about, you know, we should find out if the C committee is thinking of anything about compile time evaluation. That would be a big upgrade for C compilers. Now, for people who have one code base that is both a C and a C++ compiler, like GCC and Clang and probably Visual Studio, that may not be as big an upgrade

as someone who just has a C compiler. Right. I'd like to interrupt the discussion for just a moment to bring you a word from our sponsors. ReSharper C++ makes Visual Studio a much better IDE for C++ developers. It provides on-the-fly code analysis, quick fixes, powerful search and navigation,

smart code completion, automated refactorings, a wide variety of code generation options, and a host of other features to help increase your everyday productivity. Code refactorings for C++ help change your code safely, while context actions let you switch between alternative syntax constructs and serve as shortcuts to code generation actions. With ReSharper C++, you can instantly jump to any file, type, or type member in solution. You can search for usages of any code and get a clear view of all found usages with grouping and preview options. Visit jb.gg slash cppcast dash rcpp to learn more and download your free 30-day evaluation.

So you mentioned that the Library Evolution working group is already working towards the future to the next standard. Once C++17 is finalized, will your working group immediately have a set of new proposals to look at coming out of Evolution that will wind up in C++ 20 someday? Oh, probably. It won't happen in Kona. But the meeting after Kona is in Toronto. And that will probably be lots of people gearing up to get features into or fix problems in whatever the next standard is um you know we

we being the c++ committee have been on a three-year cycle for since c++ 11 nobody wants to go back to uh the time when nobody knew when the next standard was so right cX, which ended up not being an O anything. It ended up being C++ 11. It was OB, I believe, is how that works. Yeah. We had C++ OX and then one Y and then one Z. One Z for our European listeners. But, yeah, I believe the expectation is that there is that the next one after that, we will be targeting around 2020.

Although there are people who want to speed it up and do things every two years. So in which case there will be a C plus plus 19. We'll see. But yes, as soon as the, to answer your question directly. Yes.

As soon as C plus++17 is voted out, people will start working on features for the next standard, whatever it may be. Go ahead. I was going to say, the first standard meeting I attended, actually, was the first meeting after c++ 11 was voted out and so we were all what can we do for the next standard right i feel like 14 was a pretty successful standard like if you look at the changes between 11 and 14 maybe a lot of people don't see very significant changes but it feels like a significant bug fix and enhancement to what 11 put out. And I feel like 17 is looking like that also, like it's a solid evolution of the language in my opinion. Um,

I think it is, although there are a lot, there are a lot of people who are disappointed in the amount of changes, but I think if you look, um, you'll see that there are a lot of changes, especially in the standard library. I mean, special math file system, um, you'll see that there are a lot of changes, especially in the standard library.

I mean, special math, file system, the parallelism TS, string view, a whole bunch of library features got put in. Splicing maps and sets. You can now pick stuff up out of a set and just put it down in another set without copying all the data. Right. It's really underappreciated, I believe. But there's a lot of feeling, both inside and outside the committee,

that if it's not a language change, then it's not really that important. And people who look at the list of language changes for a particular release and say, yeah, there's hardly anything there, and that's the end of that. But there are a fair number of changes to C++17 in the language side.

I think structured bindings are going to really change the way people write code. The constexpr lambdas are really interesting. Using is a good first step. Those are just off the top of my head. There are other language changes. But there are also a long list of language changes that various people wanted and didn't get.

And so there are some people that are disappointed by that. Right. But I am curious what language feature you specifically would like to see implemented so that that would make your life easier as the library chair. Okay. I'm going to give one that's not on anybody's list. Sounds perfect. I would like Tuple to be a language feature and not a library feature.

Interesting. There's lots of places. Tuple is this general purpose thing, and it really has gotten... It is kind of the place where the intersection between the language and the library pushes the limits and it can be done in the library witness that people have done it

everybody ships an implementation of tuple but it's a really really complicated class and there are a lot of, you know, it's really hard to implement without some compiler hooks. And there are interesting problems having to do with, well, having to do with corner cases for tuple, where you get in a corner and it's like, oh, I really need the compiler to do this.

And frankly, it is a basic enough functionality that I have this feeling that it would be better off in the language rather than the library. It would be, if somebody were to do that, if the committee were to do that, it would be the second thing, interestingly enough, that lives in

namespace std that is implemented directly by the compiler rather than by the library. Initializer list? the library initializer list? yes, initializer list for the first but I don't, unless I get behind that and push, I don't expect that to happen and it's not clear to me I'm going to

have enough time to get behind that and push it will involve a bunch of interesting people on the compiler side, getting an implementation into a compiler, which would probably be Clang, getting implementation experience,

and then basically figuring out how to write it up and basically picking up a chunk of the standard and moving it from chapter whatever it is, like 19, clause 19, down into clause 4 or 5, which is where the core language lives. That's what I would like to see. Okay. Because it would make my life easier.

That's what you asked, right? Yes. What would make my life easier? That would make my life easier. Lib C++ has a... I have a guy, his name's Eric. He's a student at, in the university, and he maintains our tuple implementation, and he does a great job. But it takes a lot of his time to keep it working. That's crazy.

Okay, so that's a feature you'd like to see added or moved, I guess. Is there any feature you'd like to see removed to make your job a bit easier? Moved from the standard? Yeah. Or maybe library. Or library. Either one. We are removing things from the standard library in C++ 17.

There are a whole bunch of things. Autopointer probably being the most prominent. Unfortunately, removing things from the standard library really doesn't help me because libc++ ships and supports various language standards. We're going to have to support Autopointer

for a long time. It's just if you compile for C++17. It's still there. People will still report bugs against it. Well, okay, nobody's reported bugs against Autoporter in a couple of years. People will continue to use it, but I can't actually just up and remove it. Okay.

That's a good point. And language features, again, I don't know. Most of the annoying language features in C++ come from C compatibility. I don't see any chance that that's going to go away. There are a bunch of things like signed and unsigned conversions that bite people on a regular basis. You're just like, yeah, well, sorry. Turn your compiler warnings all the way up and then you'll catch more of

them. I agree all the way up all the way up. And, oh, and the other thing is build with multiple compilers and build multiple standard libraries. Yep. I have a friend who works.

I have to think about how to say this because I don't want to directly identify him. I have a friend who works for a large software company in San Jose who lives in a big green building by the airport. Anyway, he works on a software project, a commercial software project, which everybody knows what it is, or everybody has heard of. And when he started working on this several years ago, building with Xcode 2, so GCC 4, a build had like 10,000 warnings. And he decided that he was going to get rid of these warnings. And it took him a couple years of just part-time work. And now they build Digital Studio and GCC and Clang warning-free on all of them. And the product is much more stable.

A bunch of intermittent crashes have gone away. And as he said, it's much easier to stay at zero than it is to get to zero. When you have 100 warnings or 1,000 warnings and suddenly you have 1,002, who's going to notice? But if you have zero and then suddenly you have two, well, it's really obvious. That's a great point. Then you can

add to your build flags warnings as errors. And then your tools will tell you, hey, you had a warning here. So, yeah, building with multiple compilers, building with multiple standard libraries, it's a good thing. Running with the sanitizers, address sanitizer, undefined behavior sanitizer, memory sanitizer, they will all help make your programs more robust, I guess is the best word. And it's nice that sanitizers run on both Clang and GCC.

Well, ASAN does and MSAN does. Some do, right? Some do. Do you know if it's on the roadmap at all for Visual Studio to have any sanitizer support? No, no, that's not your area expertise. Just thought maybe you would have heard rumblings. No, they have their own set of tools.

But also, Visual Studio now incorporates Clang. You can build everything except Win32 applications in Visual Studio with Clang. And that supports ASAN and MSAN and so on.

Yeah, that's a really, that was an odd thing for me to see Visual Studio shipping Clang. Right. The new world. The new world. And meeting the Visual C++ product manager at an LLVM developers conference.

That was also... Microsoft sent, at the last European developers conference, Microsoft sent six people. That's a significant amount of money to send six people to Europe for an LLVM developers conference. That's pretty amazing.

So I saw a couple of comments about the possibility of a new language feature that would allow overloading of functions based on constexpr. And I don't know how fleshed out that concept is, but I was curious if you had an opinion on it. I don't really have a strong opinion on it. Certainly there are a bunch of algorithms in the standard library that require some kind of temporary memory, allocating some temporary memory, which is obviously not something that's going to happen at compile time. Right. On the other hand, there are other versions of those algorithms that are less efficient that may not

require scratch memory. What I'm thinking is what people want is they want the ability to choose, say, if I can allocate memory, do it this way, and yes, it will be less efficient, but it happens at compile time. But if I can't, if I can allocate memory, do it this way. And yes, it will be less efficient, but it happens at compile time. But if I can allocate temporary memory, do things in a more efficient manner.

Right. The bits in the, you know, the things in the standard, the algorithms and standards are specified in terms of complexity guarantees, whether it's calls to comparisons or swaps or whatever. And some of them, like merge, it's really hard. Nobody has figured out how to do some kind of merge, I think the in-place merge, without actually allocating some scratch memory

to satisfy the complexity guarantees. So it wouldn't surprise me if there's some interest in that. I haven't spent a lot of time poking at that because well, the C++17 features are stacking up in LibC++ and I would like to get them all done.

LibC++ stacking up in libc++ and I would like to get them all done libc++ shipped a full c++14 implementation before ISO printed the standard and so we're not going to be able to do that for c++17 it's just too much work but

I would like to get as much as possible out there in the world ready to go for the whatever, the release, the fall release. And if I can get all of C++17, well, that would be a miracle. But if I can get everything, say, other than the special math stuff, that's kind of a goal. Okay. Right. Okay. Well, Marshall, where can people find you online? Well, I am on Twitter.

I am mclow. Oops, sorry. I am mclow on Twitter. I don't actually poke. I don't do a lot of C++ stuff there. This is more of a social thing. I have a blog that is very, very occasional, like three or four times a year when I run into something that seems really interesting and I feel the urge to write.

It's called Marshall's C++ Musings. Those tend to be more philosophical. Here's a chunk of code. This is why it's this way, as opposed to deep diving into some particular thing. I wrote an article about splitting, splitting a string, and basically talking about what would be a good interface, why different interfaces would be preferable under different circumstances, what kind of splits do people want to use, and how interfaces are really important. I think the title of the blog post is,

Sometimes You Get Things Wrong, because basically I pointed out that the original STL proposal had an API mistake in it, and then when I defined the searchers for the library fundamentals TS, I replicated that mistake when you search for a pattern in a in a corpus basically std search will return to you the start of that pattern it should really return to you a pair of iterators which say here is where the pattern is right if you have you know random access iterators and you know the length of what you're searching for, getting the end

iterator is easy. It's cheap. It's constant time. But if you had forward iterators or bidirectional iterators, you have to actually advance the iterator that many. And that's an order-and-operation. And also, if you were searching using, say, I don't know, a regular expression

where you didn't know how long it was, then how do you know where the end of what you found is? So anyway, um, that's the kind of things I write about in my blog. I think things that, that come become interesting to me and that I, um,

uh, that they are philosophical more than, but they, they definitely are technical as well. Okay. Okay. Well, thanks so much for, uh much for your time today, Marshall. Oh, you're welcome.

Thanks for having me on. Thanks for joining us. You guys are going to be an award-winning podcast. I should be on it, right? Yes, indeed. Okay. Thanks again. You're welcome.

Thanks. 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 left kiss 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