CppCast - libc++

Episode Date: January 31, 2019

Rob and Jason are joined by Eric Fiselier to talk about libc++ and his contributions to the library. Eric is as Software Engineer at Google working on Abseil and other core libraries. He is also a maintainer of libc++ and active member of the standards committee. In addition to writing C++ libraries, Eric enjoys hacking on Clang. Most recently Eric has been interested in using tooling to make C++ code healthier. News C++ Productivity Improvements in VS 2019 Preview 2 Pre-Kona 2019 C++ Standards Mailing Italian C++ Conference 2019 Call for sessions Core C++ Early Bird Tickets End Tomorrow Eric Fiselier @Eric01 Eric Fiselier's GitHub Links libc++ documentation constinit proposal P1337 Aliasing the standard library as a means to save C++ C++Now Volunteer/Student Program Sponsors Backtrace Hosts @robwirving @lefticus

Episode 185 of CppCast with guest Eric Fisslier, recorded January 31st, 2019. This episode of CppCast is sponsored by Backtrace, the only cross-platform crash reporting solution that automates the manual effort out of debugging. Get the context you need to resolve crashes in one interface for Linux, Windows, mobile, and gaming platforms. Check out their new Visual Studio extension for C++ and claim your free trial at backtrace.io. In this episode, we talk about papers going to the upcoming ISO meeting in Kona. Then we talk to Eric Fisslier from Google. Eric talks to us about his contributions to Lipsey++ and his work on the AppSale team. Welcome to episode 185 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host rob irving joined

by my co-host jason turner jason how you doing today i'm all right rob how are you doing i'm doing okay um i think we should make a quick programming note uh that we're probably not going to have an episode next week right because you're going to be in folkstone yes uh c++ on c c++ on c and C++ on C. And it's not too late to buy tickets, just for the record. That's right. So if you're in the area, you can still go. And I'm going to be at a boring work thing as well, but because we're both traveling,

it's going to make it difficult for us to try to do an episode. Yes. Yeah. But we should be back the following week. Yes. We should be back the following week. We have something planned, even, I think. I think so. I think so i think so yeah uh at the top of our episode like through the piece of feedback uh this week we got this

tweet from rob bernstein and he wrote cpp cast what in your opinion is the best book from which to learn modern c++ or are there multiple books you recommend for someone getting started with the language? What do you think, Jason? Do you have any book recommendations? The only book I ever recommend when this kind of question comes up is Bjarne's smaller book, A Tour of C++. And I believe it just got an update that includes 14, 17, something like that. I knew an update was due um but other than that for something that's going to give you a good like i don't know i don't even know yeah i haven't read that one myself but it sounds like a good one for someone getting introduced into c++ if you're maybe

already a c++ developer but using like 98 or 03 then uh maybe look at Scott Myers modern C++ book. Yeah, effective modern C++ from Scott is good. But I can't recommend it for someone who's just trying to learn the language because in some places, it gets so deep in the like spinning out, you know, constructor overloads kind of thing that it's, yeah, I don't know. Okay, well, 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. Go ahead.

Yeah, sorry, a quick update. I did just check a tour of C++ was updated to C++ 17 and even covers a few things that are planned for C++ 20. And that release was made in June. Okay, I think I'm going to go buy that because I've not read the earlier version. So I'll check out the updated one. Yeah, cool. Joining us today is Eric Fisselier. Eric is a software engineer at Google working on Abseil and other core libraries. He's also a maintainer of lib C++ and active member of the standards committee. In addition to writing C++ libraries, Eric enjoys hacking on Clang. Most recently, Eric has been interested in using tooling to make C++ code healthier. Eric, welcome to the show.

Hey guys, thanks for having me. Excited to be here. Hey Eric, as someone that's like actively involved in this, do you say Clang or C-Lang? I say Clang. I don't think I've heard it said sea lang too many times. Okay. So the people in the know say clang. As far as I've noticed. Sometimes this, you know, I say clang just because I want to just read it. But then I occasionally hear people say sea lang and I'm like, I wonder if I've been doing this wrong this whole time. Yeah, I think they're just making explicit the little joke in the name. I don't

necessarily know if you need to say it. That being said, I realize I type it more than I ever say it. You know, most communication in open source is written. So maybe everybody I'm writing to is pronouncing it C-Lang in their head. Right. Okay. Well, Eric, we have a couple news articles to discuss uh feel free to come into any of these and then we'll start talking more about uh your contributions to lib c++ and maybe abseil as well okay sounds good okay so this first one we have uh c++ productivity improvements in vs 2019 preview 2 so preview 2 just dropped last week i guess and this is just one of many posts that they put out but uh i thought it was worth pointing a couple of these productivity improvements out

um they're able to now like determine that you're missing an include and suggest and add the right include for you which i think is pretty nice it's not gonna you know i don't think it'll work for everything but you know the standard library includes It'll be able to figure out for you. Yeah, that's an interesting one. Actually, I'm slightly concerned about all these in some way. In what way? We can talk about that in a second. Well, this one, I just go, well, okay, yeah, sure, that works great, Iostream.

I wonder what the probability is that like if it parsed out um like boost headers that it would recommend some internal header that you're not supposed to include instead of the public facing header yeah exactly there's a we had a similar problem moving to libc++ and google three and it's standard libraries include different headers transitively and so you accidentally get stuff all the time that you don't mean, and how do you know that you're not supposed to, or how do you know what correct header to pull in?

I think as we move towards a modular world, this will be easier and easier once the compiler has some concept of like, hey, this module is made of these headers, and this is the public interface of it. Yeah. The one thing I'll say is, you're still being prompted to

select like, yes, I want to include IO stream. It's, it's figuring out what it thinks you need, but you still need to accept that. So if it were the case that, you know, it can pick between a boost or a standard library, I would hope that they give you a choice, you know, include this boost header or include this standard library header. Right. That's a good point. Yeah. And I guess I misspoke when I said I had some concerns about all of them. I only have another concern about the last one. What is your concern with the last one?

If I read this right... Oh no, not the last one. Wait, I thought one of these said that it could add a closing brace. No, it says quick info on closing brace. My bad. Quick info on closing brace. Yeah, info on closing brace yeah yeah sorry that's at the bottom i thought it could add a uh a closing brace and i'm like how does it know

which level you're supposed to be putting in like if you are missing a closing brace okay i just misread it you hover over your closing brace and it just gives you a little tool tip saying you know this is like the name of the method that's associated with that brace. Right. Okay. Yeah, and some of the other ones that they added resolve missing namespace or scopes. If you just write out vector, it could suggest that you either use namespace stood or add stood in front of the vector and do it for you. I thought this one was kind of funny, the quick fix replace bad indirection operands,

because I know I've definitely done that before with using the wrong one and then get a compiler and just use the other one. Right. Well, you combine these fixes with the new IntelliSense that's AI based and Eric will be out of a job. Oh, yeah. Well, unless I get to write the AI. Adapting, I guess. oh yeah well unless i get to write the ai adapting i guess have you been following that ai intellisense feature at all eric no this is the first i've heard about it it effectively is supposed to learn from your code and whatever it has available to it and then make smarter and

smarter autocomplete suggestions okay that makes that makes some sense. I mean, the amount of nonsense autocomplete has the ability of suggesting makes me think that like, you could train a good model to filter out the garbage. Yeah, yeah, it's I'm sure it's true. I haven't actually managed to like I've installed it, but I haven't actually seen it give me any suggestions yet but i also spend very little time in visual studio right okay uh let's go on to this list of all the pre-cona 2019 c++ standards mailings i feel like we have been talking about the uh the last iso meeting for so long it's crazy to think that cona's it just in like two or three weeks now right uh yeah it's february yeah yeah it's right after c++ on c yeah eric are you going to the cona Kona's just in like two or three weeks now, right? I think so. It's February.

Yeah, it's right after C++ on C. Eric, are you going to the Kona meeting? I am. Okay. How does this list of papers compare to the previous one? Because I know the San Diego meeting set a record, right? Yeah. So it's definitely getting longer and longer every time I have to go look at a mailing. When I started attending meetings in like 2015, it was a lot easier to stay on top of this.

I don't really give it an honest effort too much to read the entire mailing. But when I actually attend the meeting, there's a lot of really interesting work going on and a lot of new people coming to propose decent additions to the standard library or language. So the mailings might be overwhelming, but I think the process is really benefiting from it. So is this one actually longer than the previous one that was setting a record? I'm not sure. I'd have to actually count.

Is there anything in particular looking forward to with Kona? I have a paper on constant initialization that I'm hoping to land. So in C++, we have the static initialization order fiasco, where you can't quite tell when a variable is going to be initialized during program startup. We have a semi-fix for this.

It's called constant initialization, which if the thing you're initializing has a constant expression as its initializer, the compiler guarantees you that it will safely initialize this thing before program startup. The problem is our rules about constexpr are like really subtle and you need to be a language lawyer to understand them. And there's no way to detect whether or not you've actually gotten constant initialization. So I can change a character somewhere deep down in the initializer and all of a sudden now this thing is no longer safe to use at program startup. So I proposed a paper that adds a keyword that you slap in front of your static variable that enforces that this thing is safe to use during program startup, there's no

way this will cause a static initialization order fiasco. So I'm hoping to have that fixed in C++ at this meeting. So does it require that the thing on the right-hand side that you're calling be a constant expression? It does. So all it does is it takes the existing wording for constant initialization, and it adds this clause saying, hey, if this thing was declared with the keyword const init, and constant initialization doesn't take place, the program is ill-formed. How does that differ from if it were declared as const expression? So if you declare something with const expert, the problem is it's implicitly const. And there's plenty of static variables that you want to be non-const,

but you also want to be safe to use during program startup. Okay, so const init says you must do this before main in a safe way, but it's not necessarily const. Yeah, the initialization has to take place at compile time. You could think of it as const expert mutable is another way to spell it. Wow. What does this have any interaction with the const eval keyword that was added at the last meeting? No, not yet. Not yet. I think there might be some interactions that are needed with things like const eval constructors or destructors if those are allowed to exist. But yeah, I don't think it'll need any. So const eval requires that a function is only ever invoked in a manifestly constant expression, which is somewhat orthogonal to making sure that a variable is properly

initialized. Yeah, I actually just found a use like two days ago for const eval constructor, so I hope that is ultimately allowed. Oh, what was your use? Guaranteeing that a compile time string was initialized with constexpr data and not with a locally declared array. Oh, interesting. Okay. Yeah. I mean, obviously, I don't have a compiler I can test it with, but it seems like a good use case for me. Yeah. I think I see what you're up to. Yeah.

And Eric, this was the second revision of your paper. Did you present it earlier at the committee? I did. It got largely positive feedback. The main problem was I you present it earlier at the committee i did it got largely positive feedback the main problem was i originally proposed it as an attribute i didn't want to ask for a keyword that's a big ask normally and so i thought i'd go in with something small and the consensus in the room was that this should definitely be a keyword this is important enough that it should be lifted from an attribute so i removed a whole bunch of square brackets from my paper and I resubmitted it. Okay. Maybe at this point, the standards committee should just reserve for language use

anything that's const and then four characters after it. Yeah, I think that makes sense. Even if it, like, once we reserved that, we'll just have to name all new keywords const something so that co-await will have const await okay um for the last bit of news we have we have two pieces of uh conference news uh the first one is the italian c++ conference has a call for speakers although i think we oh no we have a month left for the call for sessions yeah i know i don't believe

we've mentioned this italian conference at all this year maybe no i don't think we have um but they actually got andre alxangescu to keynote so i think they're kind of trying to improve the or increase the scope of the conference i should say right so i don't think they had any like uh big keynotes last year that i remember i thought uh now i feel like maybe i'm crazy but i thought that they announced that they are having an english tracked oh maybe i'm thinking of a different conference maybe my bad yeah well this will be in milan Milan June 15th, and you can get more information about it on italiancpp.org. And then the other conference news is, if you're listening to this on the day it came out,

today is the last day to get tickets or early bird tickets for the Core C++ conference, which is going to be in Tel Aviv in May. Yeah, early bird, yeah, Tel Aviv. I am so looking forward to that conference. Yeah, it should be fun. I'm jealous. Are you planning to go to either of these, Eric? No, not at the moment.

I'm doing plenty of traveling. So traveling to conferences like this isn't something I have time for at the moment, unfortunately. Right. You know, on the topic of traveling and the standards meetings, as I was looking at this list of papers, I was thinking about the incredible amount of work that the standards committee members go through. And it's not that, you know, there's lots of people who write papers and submit them, yes. But then there's also the people who have to take these papers and assign numbers to them and generate the mailing and send that out to everyone. And all the people like yourself who are expected to read a considerable portion of these papers.

And then once they all get approved, all of the editing work of making sure that it actually makes sense when it's put into the next draft document. Oh, yeah. The project editors are angels. I don't know how they do all that hard work. And they get it done so fast after meetings. Richard Smith is one of them, right? Yeah, Jonathan Wakely does some as well, and then I'm sure there's more that I should thank, but don't know of. Yeah, and on that note, since we didn't mention it, this does also have N4800, which is the current draft of C++20 attached to this mailing. And I want to mention another paper. Everyone should go read P1337R0.

I don't spoil it, but it's a fun read. It's, yes. I looked at it. The standard library is a means to save C++, which doesn't do the paper justice, but it's worth reading. And the name is a bit of a giveaway, I think, as well. I mean, the number of the...

Yes. The paper was originally intended for something else, and then the author saw they got P1337. That's not nice. Well, since we've come back around to the standards mailing, is there any other papers or anything that you would like to talk about, Eric? No, not off the top of my head. I'm excited to see a lot of this stuff land, but nothing in particular. Okay. There's definitely a lot in here for our listeners to go back and look at. And many of them are updates to the papers that we've discussed on the show from our previous guests as well, Rob.

Yeah. Okay. Well, Eric, why don't you tell us a little bit about how you got involved with Lib C++? Yeah, it's a bit of a weird story. I think that the reason that I got into programming in Lib C++ in general, and now have this general interest in tooling is that I'm fundamentally a lazy person. And so if I can write code that saves me time later on, I do that, which initially drew me towards writing little libraries that I could haul around between my different CS classes so I didn't have to do things like parse flags or report errors every time I didn't have to write a new library for that.

Then eventually I started writing things like any and optional, and I got to the point that I was like, hey, I might as well see if I can try and give this to a standard library maintainer. Like I know I'm just a silly student, but let's give it a shot. So I ended up meeting Marshall at CPP now, thanks to a volunteer program that brought me there as a student. And I pitched this to him and he said, sure, if it comes with a lot of tests, you're welcome to send it my way. And so I did that. and I never stopped submitting stuff to libc++, which has been both very rewarding and very weird. So almost all of my programming experience comes from working on a standard library,

which felt normal up until I recently joined the real world. And you realize that in the real world, people are actually trying to get stuff done. I'm just sitting there implementing a spec that I've been given that is very specific and exact about what things do. And once I've achieved that goal, I'm done. I don't have to worry about like how I'm going to use this to build something meaningful for a customer. And so when I actually have to go and read user code, that's doing something bad in the standard library, I'm so confused as to why they're just not following the letter of the standard. Like, what would lead someone to write bad code?

And I realize, oh, people actually write code to do stuff every once in a while. I had no idea that you initially got involved as a student volunteer from C++ Now. What year was that? Oh, goodness, that would be 2012, 2013. Wow. And on that note, we didn't mention it in the news items, the student volunteer application process is open right now for C++ Now 2019. Oh, well, if you're a student and you're listening to this, you should certainly apply. It's an amazing experience. Changed your life, it seems. Absolutely.

I'll make sure to put a link to that in the show notes for listeners who are interested. So yeah, that does seem like it would have had to have caused a bit of, well, I mean, on one hand, you understand the standard very well, but on the other hand, a bit of brain damage that you're so used to for your first real programming experience, having to do everything in ugly mode, basically. Yeah, I've also never really had to do API design because the APIs are designed before they land in my hands. And so I've been exposed to fairly well thought out APIs, but I haven't actually gone through the act of designing too many.

Right. No, I'm sorry, go ahead. What a user needs is somewhat foreign to me i need to implement the standard so i'm still learning like yeah how to design an api with user needs in mind i guess i just threw out ugly mode out there for uh without any context can you describe to the listeners what that means i i'm assuming you know what I'm referring to. Yeah. So in order to make your standard library portable and to make your code portable between standard libraries, the standard library is very specific about the names it defines publicly. So any name that doesn't have double underscores in front of it or an underscore uppercase is secret to the implementation and users can't touch it.

And it does this because the implementation has to assume that a user pound defines every non-reserved keyword in the world that is defined by the standard. That's essentially how the code has to be written. You have to assume that anytime you type out an identifier, it either has to be defined by the standard or it has to be ugly because the user can pound define anything that isn't ugly. So effectively, all of the code in the standard library is written with underscores and capital letters, prefixing everything in a way that we're not used to seeing in any of our user code. Oh, it's hideous. I hate seeing it to this day. I was thinking about this when we were talking about the MSVC improvements,

and they had an improvement for peeking into headers. And I was imagining a user peeking into a standard library header to try and figure out the contract of a standard library function. It would be awful. Yes, I occasionally have to do that, and it's difficult to read, yes. Yeah, your IDE showing you the internals of a standard library is probably not a helpful thing for it to do. I want to interrupt the discussion for just a moment to bring you a word from our sponsors. Backtrace is the only cross-platform crash and exception reporting solution that automates all the manual work needed to

capture, symbolicate, dedupe, classify, prioritize, and investigate crashes in one interface. Backtrace customers reduce engineering team time spent on figuring out what crashed, why, and whether it even matters by half or more. At the time of error, Backtrace jumps into action, capturing detailed

dumps of app environmental state. It then analyzes process memory and executable code to classify errors and highlight important signals such as heap corruption, malware, and much more. Whether you work on Linux, Windows, mobile, or gaming platforms, Backtrace can take pain out of crash handling. Check out their new Visual Studio extension for C++ developers. Companies like Fastly, Amazon, and Comcast use Backtrace to improve software stability it's free to try minutes to set up with no commitment necessary check them out at backtrace.io cpp cast so uh what parts of lib c++ have you been involved in you know maintaining and implementing uh so i'm a jack of all trades, but the largest components I've added myself includes types

like optional and any. I've also written all of file system. All of file system? I wrote file system while I was in school, actually, before I even met Marshall. And I only just landed it in Lib C++ last year.

So I've been sitting on it for a very long time. Like seven, eight years effectively. Okay. Wow. Yeah. I think those are the biggest components I've worked on and then small stuff all around. So we're talking 2012 is when you got started in the volunteer program, right? And, if you don't mind, I believe you recently graduated from college, right? I did, finally. So doing this work on the site had some impact in your school schedule? Yeah, my undergraduate took a lot longer than it should have because I was distracted by writing a standard library and hacking on Clang. But at the end of the day, I think I came out of it knowing a lot more than I would have if I had just gone to classes.

And some of this you were being paid for? When I was in school? Not really. None of my libc++ work. Okay, so it was by choice, you chose to invest that much extra time and everything and, and learn as much as you could while getting your degree. Yeah, choice is the wrong word. I don't know if you have a choice about what you're curious about. I really like writing programming. I didn't choose it.

It's just fun, and so I can't help myself. Like, I would write libc++ code when I had another code project to write for school, and then I'd hand that project in three days late and, like, 30% off. Oh, okay. Okay, no, in all serious. No, though your, your experience sounds like, I mean, it gave you this like breadth of experience that very few people get, but what would you recommend to like the college student or whatever that's listening right now and thinking about getting involved? Um, so if you're thinking about getting involved,

do it, just choose the smallest possible thing you can do to start getting involved? So if you're thinking about getting involved, do it. Just choose the smallest possible thing you can do to start getting involved. And block out a day to do it and just learn the process because that's the biggest hurdle that a lot of people encounter. It's like, hey, entering an open source community is scary and learning how they handle code reviews and submit code is weird. So just choose a small thing that will get you

familiar with all that. And then, uh, yeah, if you enjoy it, it's very easy to get involved. The communities are very friendly and there's always work to do. Feel free to reach out to anybody in a community if you're looking to find some work. Do you have any specific suggestion for small things that could use help right now? Within libc++? There's a bug list. I don't have any off the top of my head. Normally there's a little bit of context that might be needed. Yeah, that's fine. It all depends on what you're interested in, too.

So if someone's interested in writing Clang tidy checkers, for example, I have a dozen on the top of my head that I want to implement that enforce weird rules in libc++ that are better enforced by a tool than by me. So for example, whether or not we're using reserved names is a checker that I want to write for libc++. Like, hey, is this type or is this the name of an identifier that's specified in the standard? If not, it needs to have a reserved name. So it's kind of like the inverse of what a normal programmer would need.

Yeah, it's an ugly-a-fire. Right. And then also apply a fixit that automatically makes it ugly, adds a couple underscores to it, and propagates it. Yeah, exactly. It's not a very hard Clang tidy check to write

once you have a rough familiarity with the Clang AST. But if someone wants to jump in and do it, you're more than welcome. All right. I'm sure there's someone listening that will find that interesting. Yeah. So, John, tell us a little bit about what you're doing now at Google. Yeah. So, right now at Google, I am working to transition all of our internal code base from the existing standard library we use,

which is an older version of libstdc++ to libc++. So that involves cleaning up a whole bunch of test failures and fill failures caused by people either doing silly things with the standard library or forgetting to include headers they need, or what was the one that I encountered yesterday? Oh, I had someone who was friending our containers. They had a type that they didn't want users to be able to construct, but they wanted to have some of these types in a vector.

So they made the constructors private, and then they friended standard vector, and then assumed that all of the construction of their types would actually be done inside std vector itself and not in a base class or a helper function or a wrapper or something. Right. So I've been cleaning up these sorts of things.

I have actually seen that technique attempted, and it doesn't work well in a cross-platform environment. No, no, not at all. Does the standard say anything specifically about that? Like, are you allowed to friend standard containers? Does it matter? Is it just up to you? I don't think the standard says anything about it.

It certainly doesn't guarantee that whatever you're hoping it will achieve will actually be achieved. I did a search through the Google code base to see how many people were doing it, and I only found a half dozen usages, so I don't think it's that common of a problem. That's good yeah so i guess i'm curious what has if you can speak to this what has motivated the move now from lib std c++ to lib c++ internally um so the move isn't motivated as much by the change of standard libraries it was that uh we needed to upgrade our standard library. We hadn't done that in a long time. And so that is preventing us from using all of the latest and greatest goodies that the standard library has to offer. We use Clang now for the most part,

and we have processes to release new Clang versions almost every day. And so it just made sense that since we're shipping a mostly LLVM-based stack, that when we have to do the work to upgrade our standard library, we would switch it as well to LLVM. Okay. Yeah. It's certainly been a bit of a learning experience.

When I started on Lib C++, I made a couple of changes that I thought would improve code health and make users' code more portable. So one of these changes is some of our containers static assert that the comparator you give it can be called when it's const. Because it's a very common bug that people forget to const qualify their comparator. And this will work for the most part because the container never actually uses it as a const object. And I thought, okay, well, I'll make users code more portable because different standard libraries might require this by adding a static assert. And I spent the last

week cleaning up failures caused by that static assert that I just now learned existed. And I broke this code probably three years ago when I implemented this. So I thought that's funny coming full circle to, hey, I want to make this code more portable to, oh, shoot, now this code's broken. I think what I really wanted to do at the time was release a tool that would const qualify your comparators instead of breaking your code and telling you you should fix it yourself. Right. So that is required, you're saying, by the standard that the comparator be const or callable from a const context? I think the wording says something about the comparator being possibly const and then having the requirement that it be callable from a const context? I think the wording says something about the comparator being possibly

const and then having the requirement that it be callable. So how it says it for hashers is something like a possibly const hasher is invoked with a possibly const value of this, and it should work. I have encountered this kind of extra rigor with static asserts that libc++ provides that other standard libraries don't. And sometimes like that, you're like, oh, come on, just let me do what I want to do. And other times, like we've discussed using basic string as a generic container here on the show, right, Rob? From that lightning talk, libc++ is the only standard library implementation that enforces that the templated type on basic string be trivial. Oh, yes. And we have some good reasons for this now. I noticed this the other week,

and I was somewhat surprised by it, because I don't know if the standard spells that out explicitly. It does, actually. I looked that up. Yes. All right. I was looking for it, and I couldn't find it. But there's another paper coming down the pipeline that adds a resize default initialized member to std string. So often you want to use std string as just a buffer of fights for a moment. Right. And you want to keep appending to it. Think of something like Sturcat. Every time you push a character back onto a string, it has to write two separate characters.

It has to move the null, and then it has to write your character, and then it has to rewrite the null back. And sometimes you just want to say, hey, the null is going to go in 100 positions from now. Just resize, put the null 100 positions from now, and leave the rest of that memory uninitialized. I'm going to initialize it later. Don't force me to do all this extra work. So it's a function that's required for optimization. In order to do this efficiently, we have to have, we have to require the string takes trivial character types because we're not calling their constructors. And that's only something we can do for trivial types. Right. So otherwise it would be basically undefined behavior. You'd have uninitialized objects everywhere. Yeah. Or we would, yeah, we just couldn't implement the resize default initialized function

because we'd actually have to loop and initialize every single one of the characters, which is exactly what we're trying to get away from doing. Right. When we've had Titus Winters on before, he's talked about the immense size of the Google code base. Are you kind of running into any like unique challenges when trying to move from libs to c++ to lib c++ just because of the amount of google code that is there um google has amazing tools for working in its huge code base i thought it was going to be a lot harder to get up to

pace than it was um i think the hardest thing i've run into working at Google is the build system. Bazel has very strict requirements about how you specify targets that are less flexible than most build systems. And building a standard library usually requires a little bit of flexibility from your build system. to make standard libraries build with the correct flags has been the only really difficult part of working in Google 3. Can you dive into that a little bit? What weird flags does building a standard library require? So building a standard library typically requires not linking in the standard library that the compiler normally does. So historically, the only way to do this was with a flag called no stood lib, which didn't just drop the standard library.

It dropped every built-in library, essentially. And constructing the link line that your compiler does with libgcc and pthreads and libgccs and libc is a non-trivial thing to do. And so trying to figure out which runtime libraries we're using, which unwind libraries are we linking statically, rebuilding that link line is a non-trivial thing. If you look in the compiler, it's a couple hundred lines of code that builds link or invocation, and you essentially have to rebuild that

in whatever build configuration you're have to rebuild that in whatever build configuration you're trying to build the standard library. Wow. So if I'm hearing you correctly, besides that craziness, I mean, the fact that you have to deal with that craziness, I guess, implies that you all are building the standard library, building the compiler, building the whole tool chain as part of your normal full build process? Yeah. So one of the nice things about Google is we have the monorepo. And so everything builds in the same way, whether it be your code or my code or some team's code over here that has hot air balloons in Africa, all of their code builds in an identical manner. And so as a code janitor who does a lot of cleanups across the entire code base,

when I need to wander into some bizarre package I've never heard of before, I know exactly how to build everything. All of the details are entirely abstracted from me. Wow. So that includes having our compilers and standard libraries all build as part of the main build process for the most part. So effectively, the work that you're doing is the base requirement for every other project. Yes.

It's a transition that makes sense since I started working on libc++ that I am now working on their core C++ libraries and core C++ tools. That certainly seems like a non-trivial, like no pressure kind of thing to be working on. Thankfully, we have lots of tests. Right. Are you still actively working on lib C++ outside of everything you're doing with Google? Yeah, so I obviously try and keep everything building

and working upstream. So that means cleaning up build breakages and fixing bugs. I haven't been working on too many brand new features. Most of the new features I've been working on are in Clang. I've found that more fun in my free time recently. I'm not sure what big features are coming down the line for the standard library that I'm really interested in. Maybe networking once we redesign that and it gets its act back together. So what are you working on with Clang right now? I have a whole bunch of patches in flight.

I'm almost done or done. Built-in is constant evaluated. I am hoping to land the built-in source location stuff maybe later this week or next week. And then I want to get back to working on the implementation of three-way comparisons, which is very interesting. Although one of the harder things I've had to implement in Clang, doing lookup for three-way comparison operators

is quite expensive and needs a lot of optimization in Clang to make it tolerable. I want to start with the is constant evaluated, if you don't mind, because that's the one thing that you mentioned that I am the most excited about trying to play with and no one has it implemented yet. My first patch without tests was three lines. No, I'm serious. It was three lines of code.

I declared the built-in, and then I added a switch case, and then under that switch case, there was a return, and then this magical value this other person had computed for me somewhere else. Well, when did you first try to implement it, you said? A year ago. A year ago. I was just wondering. No, you said? A year ago. A year ago. I was just wondering. No, that's not long enough ago.

Wondering if it was whatever code is necessary for determining if Lambda is constexprable or something like that, but maybe not. The work was done by someone improving built-in constant P to act more like GCCs so that Clang can compile the Linux kernel, I believe. Hmm. I guess... What that change was is they actually told the constant evaluator, hey, I'm in a manifestly constant context, or that is a context in which this expression is actually required to be a constant expression. Because the thing people forget about a compiler's constant evaluation

is that it's also used to speculatively evaluate a whole bunch of things. So normally it's not clear to the constant evaluator whether or not it needs this thing to be a constant expression or it's trying to make this thing a constant expression. And so Clang's constant evaluator has finally changed

to sort of keep that context information around. That's cool. So yeah, I'll be looking forward to that on trunk soon. Yes. Richard LGTMs the patch today, you can have it. So I guess we didn't really explain for our listeners, although I think we mentioned it a couple of episodes ago. It's a standard library utility to say, am I currently in a compile time context? Exactly. It's very useful for writing algorithms, for example, where you want to do this more expensive algorithm if you're doing it at compile time, but it doesn't allocate memory. And then at runtime, you want to take advantage of the fact that at runtime, you want to allocate memory, and you want to do this less expensive algorithm. And so you want to choose between these two

different implementations, depending on whether or not you can use resources like memory and stuff like that. Right. This reminds me that one of the papers that's out that's been, I guess, to a couple of meetings now is making CMath constexpr, and it seems like this would be a helpful step towards that. I'm sure it probably would be. I think a lot of that will be a slightly different problem. The compiler likes to intercept or provide built-ins for a lot of CMath, and so it would probably be up to those built-ins to actually do the compile time evaluation.

Right. And I think a lot of them already do. If you test GCC's math built-ins directly, a lot of them are usable in constant expressions. Yes. Yeah. And other compilers, even if they're not usable in constant expressions, you can play with it in Compiler Explorer and be like, but you're doing it at compile time. I know you can. Yeah. I have to go out and write a bunch of warnings

for std is constant evaluated because it's very easy to use incorrectly. I think something like 30% of the examples I've seen using it are using it wrong. The most common is people writing if constexpr std is constant evaluated. That is just a very fancy way to write

if true. Because the operand of an if constexpr statement is a manifestly constant expression. It has to be. What they were trying to write was if is constant evaluated. Oh, I kind of wondered about how that would actually be used. I see your point. So then you might have to have an if constexpr nested underneath that if statement, depending on what your actual design goals are. But that top level if statement can't be if constexpr.

Yeah, you probably don't even need an if constexpr. So people forget that only the evaluated branches of a constexpr function actually have to be valid constant expressions right so i can have if false throw and that is totally fine thing to write in any constexpr function because despite throw not being allowed in constant expressions i never actually evaluate it same thing with calls to new or malloc you can write a whole bunch of non-constexper function calls in a constant uh constexper function so long as you never actually evaluate them right so just guarding against it being in a constant constexper context compile time context is all that's necessary yeah right all right cool uh so we're talking really about um you know

people contributing to libc++. If someone's interested, is there any particular part of the library that could use some help today? Let me... I mean, yes, there is a part, and I would love a volunteer for it. We need someone to improve regex. I don't think anybody has touched that since it was initially written, and it's a mess. Kostya has graciously filed a whole bunch of fuzzer bugs against it that include giant, like, 4 kilobyte inputs that then generate a crash. But there's plenty of work to be done there.

If someone has a PhD in mathematics, we still need the special math library. So special math was approved for C++17, correct? I think so. Yeah, it's been on our to-do list for a while. I don't think any meaningful work has been done towards it. I'm going to pull that one up. Math special functions, that's what we're referring to, right? Yeah, special underscore math, basically.

Okay, so associated... Oh, it's all words i can't pronounce basically elliptic integral of the first kind if these make sense to you hermite polynomials ryman zeta functions contact eric and he'll make sure you're working on the right thing yeah if you know what those mean you seem perfect for this if i have to write it the first step will be going back to school. So that leads me to another question here. Abseil, as I understand it, is like a glue layer, right? It helps provide things that the standard library that you currently get to work with don't provide. So it seems like in some of your transition that you're currently working on at Google,

you'd be moving away from Abseil to Lib C++ things, or no? Internally, perhaps. So there's a bit of a misunderstanding about what Abseil's goal is. I think it's probably better stated as Abseil's goal is to allow code written inside Google 3 to be portable outside of Google. So we want to provide this glue layer where if you, so a great example is Absol StringView. I want to use StringView internally everywhere because StringView is great and I love it. But then I also need to release my code in the open source world and have it usable in C++11.

And that's where Absol comes in. It's like, oh, hey, well, here you go. We have a fallback StringView type for you. You can continue to use this. And so the code that they release outside of Google and have inside of Google is the same code. So it's meant to bridge that gap for internal Google users. Okay. Okay. And so often that includes backfilling standard library types and other luxuries that we have within Google that we wouldn't have outside of Google if it weren't for AppSale. Right. Okay. In addition

to backfilling, are you also, you know, kind of getting ahead of the standard or what's available in something like libc++ um so we're definitely adding things that we think are needed stir format is a great example of this i don't know how much work is actually being done to train standardize these parts of the libraries that aren't coming up for standardization yet. I think we should. I've been meaning to make an effort for some of our better interfaces. Like, I hate writing printf calls, and I have to do it all the time, and they're unsafe,

and I want them checked by a compiler. And we have a function that does all of this magic, and it's something I think C++ should have as well. Yeah, well, and libformat is underway for approval for that kind of thing as well, too. Okay, yeah, I haven't been following it. That would be great, too. We just need a better story than we currently have. We do, yes.

Yeah. Okay. Well, is there anything else you want to talk about, Eric, that we haven't brought up already? No, I think we've covered a lot of what I'm quite interested in. I'll perhaps mention going back to the mistake I made with libc++ static asserting the constant comparator. I've been thinking more and more about how to improve these sorts of situations to make code healthier. And so in the next couple of weeks, I'm hoping to propose something that instead of

an extension to Clang that instead of allowing me to Clang, that instead of allowing me to warn the users that their code is incorrect, will actually allow me to insert fixits into their code diagnostics and actually rewrite their code for them on the fly. Not as a separate Clang chidee check, but as an actual part of the active compilation. my idea it is a pipe dream is that every vendor of a library would be able to specify in some magic pragma format let's pretend the clang tidy checks to run on code that use the library and that way you'd be able to correct users who misuse your code as they type it essentially, or as they compile it without ever once breaking them. That sounds risky.

I'm sure it will be. I mean, I risked breaking a whole bunch of code and I've been paying for that. So yeah, but this will be less risky. I'm thinking like, what if the author of the library put something malicious in? So sure, that's a concern.

If I'm calling into a library that has a malicious author. Then you already are. I shouldn't be using that library. Yeah. Right. You're already passing the execution of your program. Okay. All right.

I give you that. What about the possibility of introducing like an ODR violation if some function is compiled with one way and then linked with a different way, so it has your transformation in one direction but doesn't in the other? Oh, yeah, that's certainly, I mean, I will cite Titus at this point and say, live it head and compile your code from source. Binary artifacts are the devil. You're going to run into that problem any time you're trying to update or change code that depends on binary artifacts. Perhaps.

I guess I was thinking, even if it was a clean build and you had one object file that included the header that had the transformation, or once... Let's see, how would that happen? Would that happen? Maybe that wouldn't once uh let's see how would you how would that happen would that happen maybe that wouldn't happen like i'm thinking it would an inline header defined function one direction includes the transformation and a different one it doesn't and then the two object files get linked together well so here's how i was imagining this would happen you would

compile your code you would see an error and it would have a fix it hint with the uh suggestion to turn on minus fix to actually apply the fix your code wouldn't compile oh okay you would see an error and it would have a fix it hint with the suggestion to turn on minus fix to actually apply the fix. So your code wouldn't compile. Oh, okay. You would rerun it with the fix. It would update the source files and then your build system would then figure out all of the dependencies that it needs to do. Okay. It would rebuild it all. I misunderstood. I thought you were saying transformations that happened at compile time and you were blind to them. No, let me give a better example and perhaps a more motivating one. Consider the deprecated warning.

Everybody turns that off in their code, which makes it useless because first off, it doesn't actually help you transition your code, and second off, every person and their dog has a deprecated interface. I'm forgetting the second problem. The idea would be instead of slapping on deprecated on your function, you would specify deprecated on your function you would specify deprecated and then like the function that they should be calling instead and whatever information the compiler needs to do to do that transformation and so when i deprecate something in my library

instead of just saying hey this thing's deprecated i'm gonna say hey here's this this thing's deprecated and if you type minus fix will give you the new interface immediately. And so that will allow the library author to not only move faster in terms of improving their interfaces, but would mean less breakage to their downstream users. Okay. Okay. Could be cool. Yeah.

Well, it's been great having you on the show today, Eric. Uh, where can people find you online? Um, online. I am Eric WF on Twitter,

uh, or otherwise my email is Ericic at efcs.ca or if you need to find me regarding lib c++ any combination of eric and lib c++ should reveal all the relevant information okay it's been great having you on thank you thanks guys all right thanks thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too.

You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash CppCast. 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 was provided by podcastthemes.com.