CppCast - fmt

Episode Date: April 18, 2019

Rob and Jason are joined by Victor Zverovich to discuss the fmt modern formatting library and the proposal to bring it to C++20. Victor Zverovich is a software engineer at Facebook working on the Thrift RPC framework. Before joining Facebook in 2016, he worked for several years on modeling systems for mathematical optimization. He is an active contributor to open-source projects, an author of the {fmt} library and the ISO proposal P0645 to add a new formatting facility to C++. News eclipsecon: Docker Container Build/Run/Debug Support for C/C++ Projects Professional, zero-cost setup for C++ projects (1 of N) In-Editor Documentation for Cmake in Visual Studio Understanding when not to std::move in C++ Announcing CPPP - Paris 2019 Victor Zverovich @vzverovich Victor Zverovich's GitHub Links fmt - A modern formatting library P0645 - Text Formatting P1361 - Integration of chrono with text formatting Sponsors Wanna Play a Detective? Find the Bug in a Function from Midnight Commander False Positives in PVS-Studio: How Deep the Rabbit Hole Goes Hosts @robwirving @lefticus

Episode 195 of CppCast with guest Victor Zverevich, recorded April 17th, 2019. Sponsor of this episode of CppCast is PVS Studio. PVS Studio is a static application security testing tool for detecting errors and potential vulnerabilities in the source code of programs written in C, C++, C Sharp, and Java. In this episode, we discuss StoodMove and some conference news. Then we talk to Viktor Zverevich from Facebook. Viktor talks to us about the format library

and the proposal to bring modern formatting to C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how's it going today? I'm all right. How are you doing, Rob? I'm doing fine. You're back from your trip, right? Back from my most recent trip, yes.

A little bit jet lagged, but I think I'll make it through this interview today. That's good. Did you have a good time in the Netherlands? I did. It's always fun to go there. And I've worked with several companies in the Netherlands now, and it's always great. And in the back of my mind, I'm like, well, all right, as soon as I get home, pretty much,

I'm getting ready to go to Israel. Yeah. That is quite soon, just a few weeks now. Okay. Well, at the top of Arizona Lake, a piece of feedback. This week, we got a tweet from Jagrut Dave, and he's saying, CPPcast, regarding your April 5th episode,

I can build debug C++ inside a Docker container on a MacBook using Eclipse. Docker support for Eclipse was announced at EclipseCon, and he sent us a link for a presentation made at EclipseCon 2017. And this is in reference to someone asking about, you know, IDE support for debugging in C++ Docker containers. And I think they said that VS Code seemed to have the best support. But this listener, I guess, is having a good experience with Eclipse also. I, first of all, didn't know there was an Eclipse con.

No, I didn't either. Second of all, I was out of date enough with my docker knowledge not realized that it had mac support now which i know it did not from the beginning it started off just linux right yeah yeah yeah it's pretty cool but uh yeah i guess there's this eclipse plugin if you're using eclipse and want to debug inside a docker container you should check it out okay uh 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 cbcast.com and don't forget to leave us

a review on iTunes. Joining us today is Victor Zverevich. I forgot to ask you how to pronounce your name. You did. I was just like... Can you quickly just let me know how to pronounce your last name so I get it right? I'll just watch you struggle. It's Zverevich. Zverevverevich okay so i'll just do that intro again joining us today is victor zarevich

victor is a software engineer at facebook working on the thrift rpc framework before joining facebook in 2016 he worked for several years on modeling systems for mathematical optimization he's an active contributor to open source projects, author of the FMT library and the ISO proposal PO645 to add a new formatting facility to C++. Victor, welcome to the show. Hello. Thanks, Hugh. Thanks for inviting me. We will certainly talk about your format library a lot in a few minutes here. But I feel like, I mean, like, I know full well that Facebook has employed lots of great C++ developers for many years, but I'm still somehow

just a little bit surprised each time I remember that Facebook has a bunch of C++ developers working for them. Yeah, I think it's one of the most widely used languages at Facebook. We have a talk by Louis Brandy about curiously recurring bug patterns, and he mentions some numbers. used languages at Facebook. We have a talk by Louis Brandy about curiously recurring bug patterns,

and he mentions some numbers. Okay. Yeah, I know. And there's always Facebook developers at CppCon giving presentations with really interesting stuff. What exactly is the Thrift RPC framework that you work on at Facebook?

It's an RPC framework which you work on at Facebook? So it's an RPC framework which allows you to communicate between services at Facebook. It's kind of similar to gRPC if you heard or Google

Protobufs in the same area. So basically it provides an IDL language from which we can generate serialization code and representation of objects in different types. And also it provides an RPC mechanism to communicate between services.

And this is one of the projects. Is this one of the projects that's available from Facebook that's open source? Yes, it has been open sourced twice. So once as Apache Thrift, and then it was unfortunately forked and re-open sourced as FB Thrift, which is now...

So both are developing independently. So FB Thrift, which is now... So both are developing independently. So FBthrift, which I'm working on, I think it's more actively in development. Did it originally start as a Facebook project and then go to Apache and then back to Facebook? Right, right. That was the history. Okay. That's kind of funny kind of interesting yeah okay well victor we got a couple news articles to discuss feel free to comment on any of these then we'll

start talking more about uh the format library okay okay okay so this first one we have is a professional zero cost setup for c++ projects and it's a part one of N. And yeah, I mean, we always talk about zero cost abstraction with C++. And the author of this blog is trying to apply that principle to setting up your development environment. And he just the first of I guess, many posts that he's planning on making, but he's just walking through simple setup using uh cmake to uh get started right yeah it looks like clean modern cmake layout and it looks like might be following that um that file layout thing that uh my vector of bull proposed i i do remember that post as well and you know what i'm talking about yeah yeah i remember i know you had like a catchy name for it but i can't remember what that was now are you

familiar with what we're talking about victor are we just talking to ourselves here uh yeah i think i've seen similar uh posts recently and uh regarding this particular post uh one useful thing that i learned from it is that passing cxxX to the project command skips C compiler checks. So I tried it in FMT and it saved like one and a half second, which doesn't seem like a lot, but it's actually 30% of all configuration time. It's a great tweak and it's just a one-liner. But I'm not a fan of preventing intree builds. It's not in the post, but looking at their GitHub repo,

they discouraged that. And I think if you are a user of the library, you don't want to work on it. It's easy to just go in the root directory of the project, build it, and install without extra step. Interesting. Yeah, I think I've always done the CXX on the project built and installed without extra step. Interesting. Yeah, I think I've always done the CXX on the project setting there,

but just because that's what I've seen in other examples. Yeah, I missed that somehow. Okay, next. Oh, go ahead. Pitchfork, by the way, is the C++ project conventions. And I don't know if it strictly follows that or not, but it looks kind of similar. Yeah.

Okay, next thing we have, it was only a few weeks ago, I think, that the Visual Studio 2019 release went out, but they're already talking about the first patch. 16.1 Preview 1 is available, and one of the features in that new version will be in editor documentation for cmake basically intellisense for cmake which is pretty cool so if you're using their cmake project support then you'll get you know intellisense like hints as

you're writing out your cmake file i kind of hope that this eventually leads to the end of Visual Studio projects. I mean, they've been working a lot on the CMake support ever since they first introduced it. I'm not sure if that's a long-term goal of theirs or not, but I think they really want to support CMake just as well as they support their own build system. Yeah, and I don't know if they'd ever want to fully deprecate it or not, but if you need to do anything programmatically with Visual Studio projects, it's just a huge pain. Like if you need to change project settings or something

or upgrade things, and I've been dealing with some of that even recently. Yeah, everything's in the IDE. Yeah. It's hard to do it by command line or something. Okay, next thing is understanding when not to stood move in c++ and i thought this was a pretty good article going over some of the situations where you wouldn't want to use a move and the reasons why you know what kind of trouble you can get into yes there's um there's one comment down here at the bottom about this automatic, what's it called?

Compiler, it says, because the GNU C++ compiler implements core issue 1579, the it's still in the court issues defect reports, does that mean it has not been merged into the standard? Do either of you know? I don't know. Victor? No, I don't know. Okay. Well, this proposed resolution that apparently GCC implements is from 2013 and it says the result of an expression of return statement could be uh with automatic storage duration blah blah blah uh can automatically basically move instead of doing a copy out of the

value there in that example and it's just this i guess it's kind of an esoteric thing for me to have picked up on but since i'm always thinking about like this kind of thing and how to efficiently write c++ i feel like i need to do some more research on that. Anything else you wanted to call out in this article? Not for me. Okay. Okay, and then the last thing we have is yet another conference announcement

announcing CPPP, which is a C++ Paris conference, which is going to be in June. Wow, June 2019. That's coming up really soon. And I think we're actually going to have a couple of the organizers for CPP Paris in a future episode. So we'll be talking more about it then and as well as other things. But yeah, it's always great to see more new conferences and they have uh kate gregory for the keynote which is great it looks like they lined up all the speakers and never actually made like a call for papers as far as we were aware anyhow yeah i i guess they must have with only with having it be in june yeah a stealth speaker announcement maybe a single day conference in paris with three tracks it's very interesting idea yeah and uh

yeah awful news out of paris this week unfortunately but uh you know it's good to see that they're having their own conference well i guess for our listeners that sounded kind of ominous like there's nothing left of paris or something so perhaps yeah who weren't paying attention wasn't paying attention unfortunately the cathedral of notre dame uh had a fire and the spire fell yeah the spire fell but it looks like the main structure somehow basically miraculously survived a blazing inferno for like five hours yeah and they are planning to rebuild everything yeah uh okay so victor do you want to start off by telling us about why you decided to write your own formatting library? Sure. So back in 2012, I was writing a parser and needed a way to report diagnostics from it. And iStreams were too verbose and mixed parts of the diagnostic message with arguments, which wasn't very convenient.

And Stata was unsafe and not extensible. And at the time, I learned about Clang's Diagnostics API, which was kind of what I need. You could provide a message and feed arguments through the insertion operator. It had some limitations, and I couldn't also use the whole Clang code base just for this. So I decided to write a simple library with a similar API.

I thought it would take a few days and C++11 wasn't widely available back then. So I used the weird trick of having formatting function return a temporary object where you could feed arguments through the insertion operator and it would do formatting in the destructor it was horrible and i eventually eventually replaced it with the variadic function templates first emulated through variadic macros and then the real

variates okay so you started pre c++ basically, and then upgraded to C++11. And now I have to know, like, did you... What... Well, shoot, we're kind of getting ahead of ourselves here. But I'm very curious what standard is currently required to use your library. So currently, the current release requires some elements of C++11. So basically variadic templates, some type traits, auto, but not much. So it compiles on GCC 4.4,

which is 10 years old. If you use an even older compiler, you can use branch 4, version 4, which is not actively developed, but still maintained. I accept fixes, and someone recently implemented Gorlund C++

support there. Okay, so since we got ahead of ourselves, maybe we should go back and you should tell us a little bit more about the library. It's a formatting library. Yes. That you wanted to use for logging. Kind of. We're reporting diagnostics, compiler-diagnosed error messages,

and things like that. Okay. So how does its usage actually look? Right now? Mm-hmm. So it's just a... The main kind of entry point is a format function, which takes a format string

and a bunch of arguments that are basically interpolated into the string where you specify where to put arguments through the curly braces syntax. The syntax is based on Python's str format, if you're familiar with that. It's quite popular. Rust has pretty much the same thing, and it resembles also C Sharp's format feature, although the syntax is a little bit different. So you worked for Facebook, as we mentioned already, and I believe Folly has its own formatting library,

and there's also a Boost formatting library. you know what what reason did you have to to make your own as opposed to just using one of those other options well I've evaluated all the options and uh couldn't find one that really fits all my requirements so uh uh so the fmt library shares a lot of features with each of the other individual libraries, but what sets it apart is the combination of features. So it's lightweight, it's 3D, safe and extensible as iStreams, and more performant than most other options. In particular, Boost's format was very slow. I was thinking about using that, but it was horribly slow.

So does this work at all tie in with the project that you currently work on at Facebook, Thrift? Not really. It's completely unrelated. It's sort of my hobby project that I started before joining Facebook. I brought it in, but now we're thinking of moving from Folly format to FNT. So I think it's public knowledge

because I recently submitted a patch to Folly, which is in Git repo, which adds FNT as a dependency. Wow. That sounds like pretty big news. So you're the first people to know that, because no one looks at the GitHub comments. So then, you started before you started working on Facebook.

How long have you been working on Format now? So I started in 2012, so seven years. And you specifically chose an older compiler support, to support older compilers, that is. Yes, so at that time I needed to support older compilers because of some third-party dependencies,

but I decided to continue that. People often request this as a feature, maximum portability. Right. It's one of the features of the library. Okay. So there's obviously more we can talk about with FMT, but I'm curious about when you decided to start working on the standards proposal

that was based on the FMT library? So it started around 2016 when people started suggesting that it would be nice to have this sort of functionality in the standard. So I posted on CPP Reddit in August 2016, asking if there is interest for me to prepare such proposal and the reddit crowd was very enthusiastic So I wrote to Howard Hinnant for advice and he encouraged me Working on this and provided some useful tips Regarding standardization. So ten days later. I had a first draft of the paper, but it took the whole year until I got to the first census committee meeting in Toronto in July 2017. And what was the feedback that you got in July of 2017?

It was very positive. The paper was not ready for prime time it was my first paper wording was horrible as it turned out I didn't even need to have a wording at that time just a design kind of discussion but people were

very supportive and encouraged me to do some changes and come to the next meeting with the updated paper, which I did. So I attended all but one meeting since then. Okay. And how has the progress gone since then? So the paper has been accepted by the library evolution group. So the design is accepted, and it passed a few iterations at the library working group, so the design is accepted and it passed a few iterations at the library working group,

which looks at the wording. So I think wording right now is in reasonably good shape. So the paper is targeting C++20, but it hasn't been accepted yet. Right, but because it already went through library evolution, it still can be accepted at a future meeting before 20th finals, right? Yeah, so if it's accepted in Cologne, it will go to C++ 20. If you were to take a guess, what chance do you think it has of getting accepted in Cologne? Oh, I don't know. I don't want to guess. I'm working hard, and the library working group was very helpful.

They spent hours of telecom time reviewing the things, so I'm hopeful that this will happen. Will you be attending Cologne 2 then? Definitely. Okay. I wanted to interrupt the discussion for just a moment to bring your word from our sponsors. PVS Studio performs static code analysis and issues warnings for fragments of code that are likely to contain errors and potential vulnerabilities. The tool supports the C, C++, which enable you to detect dereferencing of null pointers, array bound violations, typos, dead code, resource leaks, and other kinds of errors.

PVS Studio supports working with Visual C++, GCC, client compilers, as well as a number of compilers for embedded systems. The analyzer works in the Windows, Linux, and macOS environments. Follow the links in the description to two new posts from the PVS Studio team. The first one suggests checking your skills to find errors. For the second one, you can read about a non-obvious case of an analyzer false positive. So with, you know, the standards paper being based on FMT, when, you know, standard library implementers go to bring it, assuming it does make it into C++20, can theymt when you know standard library implementers go to bring it assuming it does make it into c++ 20 can they just you know bring over your code base from fmt or do they need to go and

rewrite it themselves like how close is the fmt library to what's in the proposal so the library is pretty close there was a bi-directional kind of movement of changes between the proposal and the library, so we have some ideas the status committee that were then implemented in FMT but unfortunately as I learned recently the

standard library vendors cannot even look at the code although it's distributed on a very permissive BSD license. So the reason for that is that BSD license has this clause, the attribution clause, and the common understanding that it applies to binary distribution that they don't want.

So I'm currently in the process of relicensing, removing that clause, but I need approval from all the numerous contributors. Oh, wow. What license are you aiming for?

BSD without the clause. Optionally, you don't have to give attribution. Is that like BSD 2 clause versus three clause version or something like that? No, it's just one clause. Oh, the BSD one clause. Well, it's already BSD two clause, I think. It will just have another paragraph that relaxes it even further.

Okay. I must admit, I have used both of the BSD license on my own projects, but I don't think I could tell you the difference between the two common ones at the moment. I have chosen that because it's one of the most liberal. I didn't know that it has some problems

with standard library vendors. Yeah, I never would have thought of that either. Well, I mean, so far you've kind of alluded to some of the things about your library. It's got Python-like syntax, and you said it's safer than the standard IO and faster than Folly and some of the other output libraries. Would you want to give some hard numbers on that? What kind of safety does it bring to us?

What kind of speed does it give to us what kind of speed does it give us that kind of thing um so the safety so the safety comes from uh using variadic templates the type information is preserved so uh you will um and also it supports uh parsing uh format strings at compile time using constexpr, which Jason, I think you will appreciate. Yes. So you can catch all the errors, well, most of the errors at compile time. The API for that, unfortunately, is not pretty right now because of the C++ limitations, but it's possible.

Otherwise, if you have, for example, a dynamic string, it will just throw an exception if you have a mismatch between formatting types and what you have in the format string. So it's completely safe in that respect. Also, in terms of memory management, it's usually automatic, although if you want to there is an optional API where you can provide a buffer and you can misuse that

if you really want. As for benchmarks, so it's usually faster than S-Printf and other options are slower than S-Printf, and other options are slower than sprintf. So I recently benchmarked on tiny format benchmarks and got like

20%. It was 16%, but since then I implemented how to optimize it. It's 20% faster than sprintf. On some inputs like integer formatting, it's like order of magnitude faster than sprint half. Yeah, and since I follow you on Twitter,

it seems you are often looking for what is the fastest way of formatting a floating point or integer number and following the current advancements in those algorithms. Is that right? Yeah, that's correct. So the only kind of input type, argument type for which FMT was slower until now was floating point because it's so difficult to implement. I didn't have time until recently, but the current master branch implements the Grisu algorithm, which gives

this advantage even compared to fprintf. Wow. Is there any kind of patent issues or anything with those algorithms? No, I don't think so. It's published in paper and used everywhere.

It's a double conversion used in Google implementation. Yeah, I don't think you can. There is a pattern for that. I have no idea, honestly. Just thought I'd ask. Sorry. I hope. Right.

I think one of the things you mentioned was extensibility. How is format extensible? So you mentioned was extensibility. How is format extensible? So in terms of extensibility, you can specialize a formatter template for your type, and this is the extension API for adding formatting support for your types. It's kind of similar to the API of std hash. You specialize for format struct for your type and then

you can inherit it from... The simplest thing is to inherit it from one of the standard formats. For example, formatter of int or formatter of string. Then you only need to provide a single format function that takes an object of your type.

And you can either write directly to the output iterator, the string representation, or delegate to the parent's format method. Okay. It's difficult to describe you want to customize parsing by the nature of things because then you need to write the parser for format specifiers through the

parse function that you put in the same formatter specialization and you put the parsed specifiers in the formatter object for later use in the format function. Does this make sense? Well, let's try to break this down a little bit. So starting from the first part,

if I just have a pair or some custom struct that's got an int in a float in it, and I want my own, I want to be able to just send that out to format with no special options options or no custom formatting options. What does that code look like? That's pretty straightforward, it sounds like. Yeah, so for that, you can just create a struct formatter specialization for pair.

Okay. And then inherit it from, let's say, formatter string. Okay. In this specialization, you put a format function that takes a pair and format context. Okay. And the easiest way is just to call format2, passing an iterator, which you take from the context. So context.out

will give you an output iterator where you write. So you put it as the first argument as format2, then you put a format string which can be, let's say, opening parenthesis, curly, comma, curlies, closing parenthesis, which will give you two arguments in parenthesis separated by a comma. And then you just pass individual components in the tuple and return the result of format2 from your format function. Okay, so it sounds like basically I take my pair and I just delegate it to whatever the compiler already knows about

for printing out something that is an int and a float or whatever the two types of the pair are. Exactly. And you write it through the output iterator because all the API is iterator-based, so you can use it with a variety of types. You can format into a string, into your own buffer, into buffer located on stack, for example.

Okay. So if then you were saying it is possible to actually specify your own custom format options. So like right now, for an integer, you can say like X or whatever, and it'll make it a hexadecimal right? Right. So I could do something like that for my custom pair printer. I can parse my own custom format string. Exactly. Okay. And that's when it starts to get more complicated. Yeah, it's complicated because then you need to write the actual parser

it's also beneficial to make it constexpr, which limits the thing that you can use unfortunately. Although it's getting better, we have more and more stuff available that constexprs have. But most of the time you just

you won't need to write custom format specifiers. And in fact, I recently learned that in Rust, they don't allow that. So you can only use standard format specifiers. Right. And you mentioned that you use the same syntax as Python's output formatting, and that Rust also uses the same Python syntax? More or less, they did some tweaks to it. I think when you

pass dynamic precision and dynamic width, they change the syntax. So in Python, you just nest the curly braces, which allow you to refer to other arguments. So in the precision field, you can

refer to another argument that will give you runtime precision rather than encoding it in format string itself. So in Python, it's just curly braces. In Rust, I think it's star or something. Okay. And does the format lib also allow that? Yeah, it uses curly braces, Python's convention.

Okay, I see. It kind of restricts it uses curly braces, Python's convention. Okay, I see. It kind of restricts it because in Python, you can put embedded substrings anywhere, but in FMT, it's only allowed for precision or width, kind of what printf allows you to do. Since you just mentioned printf, how difficult of a task is it to migrate

from printf to fmt or to the standards, assuming we get it in C++20? It should be possible with the Clang code modding tools, like refactoring tools, provided that

the format string is literal, it's pretty easy. If it's a dynamic string, it's more tricky, so you will need some kind of runtime translation of format specifiers. Although if you're using printf currently with a dynamic format string, you probably have a security vulnerability in your code.

Exactly. Well, there are good reasons for that. Well, relatively good reasons. For example, if you have a translation database or something. So of all the things that we've just discussed, how much of this do you expect to see in C++20? I mean, what does the proposal contain? So the proposal contains the core stuff,

the argument handling and the format function, format2 function that returns a string, format2 that takes an output iterator and allows you to write to any output iterator, and format2n that takes an output iterator and allows you to write to any output iterator. And our format2n that takes an output iterator and a size, it's similar to snprintf. Okay. What else?

It specified the extension API, this formatter specializations, and it supports all the fundamental types, formatting of all the fundamental types, formatting of all the fundamental types. And I have a separate paper with Howard Hinnant and Daniela Engert, which proposes formatting for chronotypes using the same facility. Okay, very cool. So, I mean, what isn't in there then? What's in the format library that's not in the standards?

Oh, even more. I always not included console output with colors and text styles, formatting of tuples, containers, ranges, Unicode support, although it's pretty basic in FMT as well,

and compile time format string checks at the top level API, although it's pretty basic in FMT as well. And compile-time format string checks at the top-level API. So it's specified that extension API supports constexpr parsing, but it's not hooked anywhere because of the language limitations. So it's kind of designed for the future. Once we have some kind of ability to provide a convenient format function API where you can process the little string easily at compile time when other arguments are dynamic, then we'll hook into this functionality and give you compile-time errors. So one of the proposals that allows that is parametric expressions by Jason Rice.

For some reason I thought that that had already been accepted, because that's also something Hanna needs for compile-time regular expressions, but I could be mistaken there. Well, the thing that is accepted is objects as a complicated name, like non-types and plate parameters or something, where you can pass a string as a template parameter. So it gets us halfway there. So you can provide an API, but it will be very ugly.

So basically you'll have to pass a format string in angled brackets. Right. It might be okay for regex, but I think for formatting, because it's widely used, it will be a pain. Okay, I understand. So, is there any way to...

I mean, you have something that's kind of printf-like. Do you have anything that's scanf-like? No. I think in general, output is orders of magnitude more used than input. Uh-huh. There is, strangely.

In particular, neither Python nor Rust, I think, provide a symmetric API, scanf-like API. But I'm thinking of proposing at least a design paper along these lines because much of the machinery argument handling can be reused between scanning and formatting. But I'm not very enthusiastic about it. between scanning and formatting. But I'm not very enthusiastic about it.

I personally think it would be a great idea. You should move forward with it. Okay. Between that and CTRE and the other regular expressions, I mean, we could just parse and do anything we wanted to do in our code after that. Sure. So you said you're going to make it to the Cologne ISO C++ meeting. How many ISO meetings have you gone to so far?

And have you just been focused on format when you go? Or are you participating in other discussions as well? I've been to five standards committee meetings so far, mostly dealing with formatting and Unicode. I'm a member of Unicode standard group.

I try to attend the meetings, although I haven't been doing that lately because I was too busy. But I plan to resume that. During the last meeting, unfortunately, I didn't have the opportunity to attend much. I was loosely following modules. But other than that, I was hanging out in library working group

hoping for my paper to be reviewed and kind of soaking in all the information and trying to learn how to write standard d's yeah and i guess for the sake of letting our listeners know the cologne is july 15th through the 20th i believe yeah 15th through the 20th and then the last meeting of the year is going to be in november in belfast right so if you are Europe, you have great opportunities for the next two standards meetings for sure. And actually the one after that's going to be in Prague and then Bulgaria. So yeah, lots of opportunities in the European region. Yeah. And Cologne is going to be the

last meeting when anything can make it into Z++20 is that right? Yes so previous meeting in Kona was the last where you could have design changes where the design was approved and this one, the next one is the last where you can have wording changes so that's why

I need to be there to have my papers go through z++20. Sorry to be there to have my papers go through. So you've basically... Plus 20. Sorry to interrupt. You have basically three months. People who are listening and they want to help out,

is there any way that you need help getting ready for Cologne? Do you need help with the standardese? If anyone is proficient in standardese, I would appreciate the look at the paper. Send me comments. Especially maybe the second paper, the Chrono, formatting of chronotypes, because that one hasn't been seen by the library yet. This one has been seen multiple times.

Are these on GitHub or something where people can submit issues, pull requests, whatever? Yeah, it's on GitHub. Okay, you can send us the links. I don't have a link yet. Yeah, sure. Okay, so is there anything else we haven't talked about with format that you would want to bring up before we let you go? Not really. I think we covered a lot of stuff. Alright. Well, it's been great having you

on the show today, Victor. Thanks. It was great talking to you. Thanks for joining us. 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. Thank you.