CppCast - <chrono> and more

Episode Date: June 28, 2017

Rob and Jason are joined by Howard Hinnant from Ripple to talk about &lt;chrono&gt;, his date &amp; time library (and proposal) and his work on move semantics. Howard Hinnant is a Senior Software Engineer at Ripple and the lead author of several C++11/14 features including: move semantics, unique_ptr, chrono, condition_variable_any, shared_mutex and std::lock. He is also the lead author of two LLVM projects libc++ and libc++abi. News Noexcept: lightweight error handling library for C++11 7 Ways to Get Better at C++ During this Summer After 17 yrs of active development, does the Boost C++ library meet its original vision Howard Hinnant Howard Hinnant Links CppCon 2016: Howard Hinnant "A \&lt;chrono&gt; Tutorial" CppCon 2015: Howard Hinnant “A C++14 approach to dates and times" CppCon 2016: Howard Hinnant "Welcome To The Time Zone" A Proposal to Add Move Semantics Support to the C++ Language Sponsors Backtrace Hosts @robwirving @lefticus Better C++/Chicago

This episode of CppCast is sponsored by Backtrace, the turnkey debugging platform that helps you spend less time debugging and more time building. Get to the root cause quickly with detailed information at your fingertips. Start your free trial at backtrace.io slash cppcast. Episode 107 of CppCast with guest Howard Hinnant recorded June 28th, 2017. In this episode, we talk about C++ summer learning. Then we talk to Howard Hinnant from Ripple. We talked to Howard about Crona, his Dayton Time Library, and Movesmantics. Welcome to episode 107 of CppCast, the only podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today?

Doing pretty good, Rob. How are you doing? I'm doing okay. I don't really have any news to share myself right now. No news? No, no real big news. Yeah. I'm in some car trouble, but we don't need to discuss that on air. Yes, but if you are curious about Rob's car trouble, you can go to Twitter

and find out about it and retweet for him. Yeah, yeah, I'd appreciate that. We're fighting with toyota right now anyway uh at the top of our episode i like threw a piece of feedback uh this week we got an email from if i'm pronouncing this right it's either niece or nice uh and he writes in hi guys thank you for the great show i found it some time ago when dealing with the beast library and totally became addicted with your podcast and he says let's cross fingers that beast will become part of boost thanks

for it do you think it'll be possible to invite gore nishinov or james mcnellis i followed their presentation at cpp con and i'm really curious about the current status maybe you can make them say a few words on the difference between their implementation of coroutines and coroutine 2 boost i wonder which implementation will make it into the standard. So obviously we have had James on before. I think we talked a little about coroutines with James. Yeah. That was a while ago, though.

But we should definitely have Gore on and do a full episode on it. Certainly. Yeah. So thank you for the suggestion, Nis. We'll definitely try to get in touch with Gore and see if we can get him on to an episode soon. 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. software engineer at Ripple and the lead author of several C++ 11 and 14 features, including MoveSemantics, NeatPointer, Chrono, Condition Variable Any, Shared Mutix, and SteadLock. He's also the lead author of two LVM projects, LibCXX and LibCXXABI.

Howard, welcome to the show. Thank you for having me. And since we mentioned Beast, I'll throw that in, too. I had a small part in that. I helped Vinny Falco with that a little bit. That's cool. We've talked about it a couple times in the news recently because

I think he just put it in for the boost review and he just announced that you can now do a little server using Beast, right? Yeah. He's been pretty active on it, I guess. It's coming along very nice. We're using it at Ripple as well.

Oh, that's cool. I was curious about that, what kind of real-world usage it had seen. It's getting industrial strength usage at Ripple. This is a financial network that's up 24-7 and has had no downtime, knock on wood, for the past, I don't know, well over a year, maybe going on two years. Wow. Using Beasts the whole time, I assume.

Yes. Oh, wow. That's great. I am curious, though, in your bio, how did you become a lead author or how did you get started doing LibCXX? That's what I want to know. Well, LibCXX, I hired on at Apple, let's see, I guess in 1995, not 1995, 2005. I'm only a decade off. And at the time, Apple was using GCC for their development tools. And I was, you know, GCC is great, but I was not personally happy with some of the design decisions that they've made in their standard library at that time. And so I just started working on a new standard library for myself nights nights and weekends while i was working at apple

and uh you know i told the apple people about it and they patted me on the head and said you know that's that's cute you know and that was about it and then i you know i continued to work on it purely as a hobby and then about a year later let's see the new GCC open source license, GPL3, came about. And Apple really is not a fan of GPL3 as just a showstopper for their lawyers. And all of a sudden, my little hobby started to be important for Apple. And so they started saying, yes, we want you to work on this full time. So that's how the C++ came to be important for Apple. So they started saying, yes, we want you to work on this full time. So that's how the C++ came to be. Wow.

So would you think it would be fair to say if you really want to learn C++, writing your own implementation of the standard library from scratch would be a way to do it? I will say it's definitely an education, no doubt. And this was actually my second, or really third time to do this. I was also the standard library implementer for MetroWorks Code Warrior way back in the day. Oh, interesting.

So I had some practice. That's a much smaller standard library at the time, I'm thinking. Yes, that's true. C++11 almost doubled the size of the library but parts of it were pretty big anyway

especially locale so I'm curious for our listeners who have not heard of CodeWarrior can you give us just a I'm certain there are listeners who haven't can you give us a rundown on what the goals of Cold War were?

What platforms it targeted? Back in the mid-'90s, they targeted just the Apple, the Macintosh desktop, which that's all there was. In fact, back in the day, Apple was in the middle of a transition from Motorola to PowerPC architecture. Okay. I believe that's correct, yes. From 68K to PowerPC, yeah. Yeah, and Apple's development tools were really not very good at the time.

They had this command line compiler that nobody liked or used, but MetroWorks was shipping their Code Warrior platform on Mac. And I credit MetroWorks for really helping Apple make that transition very smoothly. But ultimately, let's see, after that, MetroWorks branched out to Windows for a while and then went into Embedded. Excuse me. And the Code Warrior product line is still alive and well. A company named Freescale owns it now, and they target embedded systems. And I don't really know exactly which embedded systems they're targeting these days, but the Code Warrior product lives on. It's still out there. I'm mostly familiar with it in the embedded context,

but I don't think I realized that it was still being updated. I have no idea. I haven't had any contact with Freescale in years and years. Okay. Probably a decade. Okay, Howard, so we have a couple of news articles to go over, and then we'll start talking to you about Stood Chrono and all these other C++ 11 and 14 features you've contributed to over the years, okay?

Okay. Okay, so this first one, we've been talking a lot about error handling lately and there's yet another article with a new library called NoExcept Lightweight Error Handling Without Exceptions for C++ 11. Jason, I was wondering what you

thought about this one, how it compared to some of the things we've been talking about recently with outcome. I saw it does use or can use std error code, which we discussed last week with Charlie. Yeah, I was hoping you wouldn't ask me first my opinion, because this library, there's several things that just bother me. I'm not sure if i can fully articulate but first of all the name no except as a keyword yeah so uh but beside that i guess it's not technically a keyword because it's only good in certain contexts or something or however

that works out i'm not great on that part of the standard. But it says that it's zero overhead in the case where no error occurred. But I have a really hard time believing that's possible because it must use thread local variables. It's the only way this could be implemented. So your try function, a try now becomes a function, your try function takes the return value that is anything. So in this case, in the first example, open file is returning a

file pointer. And then the try function checks to see if that is null. But it also has to check to see if some sort of thread local variable was set by a previous throw statement, which is throw underscore in this code. And if that's true, that had to be thread local. I feel like it just can't possibly be fully zero overhead. But I don't know. I don't know. Yes.

I don't know the author of the library. And it just, it kind of doesn't sit well with me with the way it seems to co-opt keywords and things that are built in. Yeah, I understand that. Did you have a chance to look at this one, Howard? I did look at NoExcept. I thought your introductory words, two of them were, especially they were right what I thought, and you started with yet another.

And I was like, yeah, uh-huh. You know, not that we've got this all figured out or anything. It's good that people are still working in this area. I did find it interesting that this is targeted towards a platform where exceptions can't be used, but thread local storage can. And that's a little bit of an

odd combination. Usually if you're in a place where exceptions can't be used, we're talking embedded stuff, limited OS facilities, that sort of thing. And thread local storage usually requires quite a bit of OS support. Well, hypothetically, it could fall back to statics, maybe, if it's in a thread-disabled environment. Exactly. If it's not a threading environment, then static is the same thing as thread local storage,

so that goes away. Right. And also, this is getting picky, but I looked at a little bit of the code, and he was, Mr. Move, of course, and I was noticing some universal references that he was moving from instead of forwarding from, and I was like, oh, you know, okay. That's a no-no. Right.

So at any rate, that's the extent of my knowledge and review of of no except i i didn't really look at into it any further than that okay uh next article i have is uh from the fluent c++ blog and this is seven ways to get better at c++ during the summer i thought this was just a pretty neat list i mean i know a lot of people probably take off to some extent during the summer. We're not in the conference season, so maybe you're not actively trying to learn as much. And he just wrote this article about how to stay up to date, watch videos if you didn't watch all of C++ Now or CppCon videos. I think he put down links to your videos too, Jason. Yes. And I also

recommend maybe reading a new book or picking up a summer project like writing a library or something like that. His list of videos to catch up on is like Who's Who of CppCastGuests. Yeah.

I think he's got one of yours too, Howard, your Chrono video. Right, which I can't help but recommend. That was a good one. Yeah, I thought the article was, you know, it's a nice written article. And to me, the basic message here is one I've always thought was a good message, and that's never stop learning. You know, there's always something new to learn. Nobody knows everything, especially me.

It's always great to take advantage of some free time to learn something new. Yeah, absolutely. I like his specific advice of working on a project also. That's always a favorite of mine for a way to learn. And maybe we can suggest starting your own standard library implementation from scratch as a summer project. Maybe not that. Although, pick a piece of it, something like Vector or something like that.

It's not a bad suggestion in a know, in a microcosm. That's an interesting point, yeah. Touches everything in the standard, pretty much. Yeah. But other parts of the standard are much harder to implement. I don't suggest starting with regex. Right. Yeah.

Okay, and then this last article is uh on cppdepend.com and it's uh talking about boost and putting forth the question after 17 years of active development does the boost c++ library meet its original vision and it's pretty interesting because he has you know some discussion about when boost was first created and and what they're trying to achieve exactly and there was a lot of focus on the website itself and not just being a collection of libraries which i thought was interesting i think it's hard to say that by any measure that boost has not been a phenomenal success um just the fact that it still exists after 17 years is pretty amazing. And it's more relevant than ever. You know, everybody who gets into C++ immediately learns about Boost.

It is an amazing melting pot, if you will, of test libraries. What do you think about this conclusion that the author made that it's kind of a high barrier fun with these days, and that's GitHub. Right. Of course, you don't get the peer review, but you can get a fair amount of exposure. And if you don't have people using your library off GitHub, that probably means that your peer review is going badly. And if you do have clients using your library,

they will no doubt give you valuable feedback. So Boost is great, but Boost isn't the only gateway out there. So when you start your summer project this year to learn more C++, post it on GitHub.

There you go. I wonder if Boost would have been a thing if GitHub was around 17 years ago. I think it definitely brings a lot to the table, what with the extensive peer review and the extensive discussion list, the mailing list. But, you know, that is a good question. All parallel timelines are always hard to analyze. Right. So, Howard, in your bio, we talked about about the many features that you were a lead designer of in C++11 and 14,

one of which being Chrono. For listeners who aren't familiar with Chrono, could you give us a short overview? Sure. So Chrono is a time-handling library that makes heavy use of the C++ type system in order to catch as many common errors as possible at compile time. For example, there's separate types for time points and for durations. And a time point is like a point in time, like today or tomorrow, and it makes absolutely no sense to say, what is tomorrow plus today? That's just a nonsensical statement.

And so if you try to do that in Chrono, it literally does not compile. But you can say, oh, what's tomorrow minus today? Well, that's a day. It's a duration. And that does compile. So the type system is heavily leveraged to catch all of your logical errors like that, or as many as possible, at compile time. And a lot of the people, and this is partially my fault, a lot of people say, oh, Chrono sounds interesting. I'll look at the header and learn how to use it. And that is the absolute worst way to learn about Chrono. It's full of templates. It's full of a lot of advanced programming techniques. And looking at the Chrono header is a good way to go, oh my God, what were they thinking?

If you want to learn about Chrono, go to YouTube, search for Chrono tutorial. Hopefully you'll find one from me and spend an hour and listen to the tutorial. It's actually that the API is very simple on a conceptual level. But if you look at the header, if you look at the synopsis of the API,

it looks very complicated because it's all templated for the different units and different coarsenesses of time points and so forth. I did watch the YouTube tutorial. I thought it was really good. CppCon 2015 or 2016, I think you made that? 2016, so you're the one that watched it. I was wondering, how

difficult might it be to migrate to using Chrono in an existing code base? I'm not sure if you went over that at all in the tutorial. I don't think I did, and it's a very good question. It's an exercise that I've actually gone through several times. And it turns out that it's fairly easy to migrate from an existing system,

say, just using ints or whatever to measure your time durations, or if you're maybe using time spec or time value from C. It's very easy to migrate to Chrono because you can do it a small piece of code at a time. Chrono has API to interface with integrals either coming into the Chrono system or going back out. So you can always put in or get out that integral that represents seconds or microseconds or nanoseconds or whatever your system is. And so you just do a small piece at a time, and on the boundaries of that code that you just migrated, you can use this integral API to interface with the external, the C interface or the custom interface, whatever your current time system is. And you just grow that piece of code, expanding that boundary bigger and bigger slowly over time, running unit tests each time, you know, each time

you change things until finally you've got your whole piece of code migrated. So having it be, what's the word, do a little piece at a time, you know, it's very helpful to testing and being sure that you don't make a, you know, some, a lot of mistakes while you're doing this. So this barrier you're talking about is essentially the second-since-the-epoch kind of thing that we're used to in the Unix world? For only one of the clocks it is. System clock, it's not specified to be second-since-1970, but the de facto standard is that's what everybody's measuring, except in units finer than a second. GCC uses nanoseconds.

Visual Studio uses 100 nanoseconds, or a tenth of a microsecond. And LLVM, the library I wrote, uses microseconds. seconds. But they're all measuring time since 1970, excluding leap seconds, which makes the conversions to calendar types a lot easier. And basically POSIX started that tradition, and it turned out to be a fairly good one. But at any rate, if you're not talking about clocks, if you're talking about just durations, then there is no epic. You're talking about minutes, seconds, hours, microseconds, whatever. There's no reason to talk about epics, especially if you're doing some timing and you just say, okay, what's the time now? You run your code and get the time again.

You subtract those two and you get a duration. And in that case, you don't even care what the epic is. And there's other clocks in Chrono. There's one called SteadyClock, where the EPYC is not only unspecified, but it differs from platform to platform, and even on a single platform, it can change. On Apple's platforms, the EPYC of SteadyClock is whenever your computer booted up, and it's just running a timer since computer boot. Since the install of the operating system or since the most recent boot?

The most recent boot. Oh, okay. So it's basically a stopwatch instead of a clock. You can't use it to tell time, but you can measure time with it. You can measure elapsed time with it. There's also something called a high-resolution clock, but it's usually a type-deaf to either the system clock or the steady clock. So it's not really that useful.

It's my bad. I never should have put it in there. But at the time, I thought it would be useful, and it turned out not to be. I guess that's an interesting, good tidbit for people who are looking to move to the chrono. And you'll also find that tidbit in my tutorial. Reach for steady clock or system clock, depending on whether you need a watch to tell time with or a stopwatch to time something with. And just ignore high resolution clock. Okay. You've also written a date and time zone library that's built on top of

Chrono. What makes those libraries unique compared to something that's already out there like Boost DateTime? So as I started writing the Datetime library, I wanted it to be just as type-safe as Chrono. I wanted to catch as many compile time errors as possible. And I wanted it to seamlessly interoperate with Chrono. And so what I came up with is really not so much a separate library as it is extending the chrono library into the realm of calendars and time zones. In fact, the central theme of this library is actually nothing more than a type def for a chrono time point.

And then everything just builds from that. For example, the time point that's based on system clock, as I said, can have various coarsenesses or precisions depending on what platform you use. You can also customize that precision, the unit of time that it's measuring yourself. And so for dealing with calendars, I've created a unit of days, 24 hours. And that's nothing more than a count of days since the 1970 epic. And that is the communication channel between Chrono and any calendar in the world. If you can write a calendar that can say how many days you are before or after the Gregorian 1970 January 1st date, then you can interoperate with Chrono and you can interoperate

with any other calendar that follows that same standard. You can think of calendars like iterators. The standard creates this concept of an iterator, not a base class, but a concept. And if you meet all those concepts, you can write your own iterators and interoperate with any of the algorithms and algorithm. So like that, what I've done is I've got this concept of a calendar that just converts to and from, I call it sys days. It's this system clock time point with a coarseness of days. And if you can convert to and from that, that is the calendar concept. And that allows you to interoperate not only with Chrono, but with my time zone library and with any calendar that anybody else writes. With all this type safety and units discussion, I'm wondering, does it in any way work like the Boost Units library?

Like if I wanted to do like seconds times seconds, could I get like seconds squared back out or do any kind of dimensional analysis or anything with it? Mostly no, but to a very small extent yes. This is a consistent subset of a units library in that

it handles quantities of time with an exponent of either one or zero. And that's it. So you can't do seconds squared, but you can divide seconds by seconds and get a scalar out, you know, a time to the 0. So it's self-consistent that way with the restriction that your exponent can only be 1 or 0. Okay.

Including even the modulus operator, which can be quite confusing for some at first, a duration modulo duration still gives you a duration, believe it or not. And you can also say duration modulo scalar, and that is also a duration. Interesting. You have to work through the dimensional analysis of it. Right. At least one vendor saw the spec on that and didn't believe it and implemented it incorrectly in the early years, but that has since long been fixed. I don't believe you, so I'm going to implement it differently than what the standard says. Exactly. It's kind of funny.

Well, the standard isn't perfect. It does have bugs and stuff like that happens. So, you know, it's not that unbelievable. Certainly. So given that your libraries are kind of an extension of Corona, are you going to try to get it into the standard as well? Absolutely. In fact, I've just completed revision three of the proposal and got it into the pre-Toronto mailing. Although you shouldn't assume that because it's revision three that the committee's already looked at it. Revision zero, one, and two haven't been reviewed yet.

And the reason for that is the committee's been very busy with C++17, getting that out of the door. And that's very understandable. I am hopeful that we'll look at it in Toronto, which is just in a few weeks, in July. Don't remember the dates offhand, but at any rate, hopefully we'll get it reviewed then, and if not, Revision 4 will be in the next mailing. In fact, I've already started working on Revision 4.

It's always a work in progress. You always see something that you can make a little better or I get feedback from customers, from people using it. In fact, just in the past few days, I've had a couple of people who are using the library make really good suggestions for how to improve the proposal. You know, so maybe just a slight diversion, you've written a lot of proposals at this point. Yes. Do you have any just like what would be your, I want to write a proposal, give me a two minute, you know, best practice maybe on getting a proposal that's well written? Okay, believe it or not, the very first step you should do is one that beginners usually get right and experienced committee members often get wrong. And that is implement it and get field experience with it. Don't write the proposal first.

And you would be surprised at how many times people don't do that. And that's one of my pet peeves. I've been gathering field experience on the date proposal, for example, for years now. And I had at least a year of experience with it in the wild, people using it, before I wrote the first revision of that proposal. So do your legwork first. Get a library, or even if it's a language feature, try to implement it in GCC or Clang, which I realize is a high bar,

but it is an international standard. You've got to take it seriously. You don't want to propose something that, you know, maybe turns out to be not a great idea because we're not all smart enough to come up with a perfectly proposal, pick a piece of the standard library out of the specification that you're relatively familiar with and just read it out of the standard and get a feel for the style of specification that's needed. And then write the specification for your library. And I always like to write the specification first, and then as the very last step, I write the introduction, the descriptive stuff to tell people in more English what it's doing. I often find just the act of writing the specification will often find bugs in my software that I'll have to go back and fix or say, oh, this feature isn't right. It's amazing just the act of documenting in detail how your library is supposed to work

will further reveal problems and improve it. So you have a library that works, that has tests, and then you go to write the detailed specification and realize, oops. Yeah, it can happen. It has happened to me many times. So another tangent, you've talked about epochs and counting the number of seconds since 1970. I'm wondering, as someone who thinks about dates and times a lot, are you concerned at all about the so-called year 2038 problem? Personally, I'm not.

By that time, I plan to be retired. Hopefully still alive. We're all screwed, though. No, that's when you come out of retirement and make $1,000 an hour as a contractor. There you go. And for listeners who aren't familiar with the 2038 problem, that's going to be when, you know, if you're counting the number of seconds since 1970, it's going to overflow in 2038. Yeah. So we've got, what, 19 years to prepare for it.

I think we're actually, as an industry, we're doing fairly well at preparing for it. The main thing to prepare for it is to move your time T from 32 bits to 64 bits, which just about every platform, at least desktop platform, has already done. Okay. You can still compile things in 32 bits, and those applications may have problems. Now, interestingly enough, I notice on Apple's platforms,

their time zone files still have the 2038 bug to this day, even if you're running a 64-bit application. All of their time zone files are using a 32-bit timestamp measured in seconds, and they're all going to mess up. They all do mess up if you reach out to 2038, or if you reach back far enough in time to, I think it's 1901 and something, then time zone transitions no longer work. Now that the IANA database has already fixed this, they fixed it 10 years ago, I think. And the time zone files now

have different versions where you can have the old version with the 32 bit timestamp or the new version with the 64 bit timestamp, which is of course, which of course fixes that. But for whatever reasons, Apple has not upgraded their, uh, time zone file format to the, to the modern standard in the past decade. I don't know why. Is this like if you wanted to calculate the start of daylight savings time in 2040 today on an Apple platform, you would have a problem? That's correct. Okay. Interesting.

Yeah. They probably don't get too many bug reports about that because if you did so, it would be extremely theoretical because the politicians will surely mess you up before then. Certainly. They like to change the time zones all the time, especially the Egyptian government. They're really good at it. They say, okay, in three days it's going to change. They've done that a couple of times now. So they're great at sowing havoc. We just all need to follow Arizona's lead. I couldn't agree with you more. What is Arizona doing? Arizona doesn't... Yeah.

They have no daylight savings time. The clocks don't change. They are rock solid. That is the only sane way to go. What makes it very interesting to me, having driven around that area, is when you go from Arizona time onto the Cherokee Nation, is that right? Reservation, which is not, they don't follow Arizona time, even though they're partially on Arizona, they follow the rest of the time. And then you go back into Utah. And now you're back on not Arizona time again. And anyhow, it's interesting. Very confusing.

I want to interrupt this discussion for just a moment to bring you a word from our sponsors. Backtrace is a debugging platform that improves software quality, reliability, and support by bringing deep introspection and automation throughout the software error lifecycle. Spend less time debugging and reduce your mean time to resolution by using the first and only platform to combine symbolic debugging, error aggregation, and state analysis. At the time of error, Backtrace jumps into action, capturing detailed dumps of application and environmental state. Backtrace then performs automated analysis on process memory and executable code to classify errors and highlight important signals such as heap corruption, malware, and much more. This data is aggregated and archived in a centralized object store, providing your team a single system to investigate errors across your environments. Join industry leaders like Fastly, Message Systems, and AppNexus that

use Backtrace to modernize their debugging infrastructure. It's free to try, minutes to set up, fully featured with no commitment necessary. Check them out at backtrace.io slash cppcast. You were one of the lead designers on move semantics and rvalue references, right? That's correct. So I guess I wanted to start by asking what was your role, but yeah, so how did you come up with this? Who did you work with? Well, at the time, this was back when we had use groups. You guys, do you ever heard of comp.thing.c++? Jeez, it's now been so long I'm forgetting the names.

We used to have newsgroups. I know what newsgroups are, but I think Rob might be too young. Definitely wasn't a part of them. I think they may even exist. I check in on them about once a year and say, oh, wow, yeah, people are still posting on that, but not very many at any rate. This was back in the 2000 timeframe or so, or 2001. And people had been discussing the idea back and forth on these news groups about, you know, best way to tackle it and stuff. So it definitely wasn't something I invented.

It was just a project that I took on. At the time, I was working for MetroWorks as their standard live implementer, as I mentioned before. And I wanted to make my vector faster than anybody else's. And that's basically how this all got rolling. especially when a vector reallocates a new buffer under the hood and needs to quote-unquote move elements from the old buffer to the new, or when you insert into the middle of a vector and it needs to scoot everything up or down. This is ideally made for move semantics.

It's just a perfect fit. And so I started working on it and fooling around with it, and MetroWorks was extremely supportive of my work. In fact, the lead compiler engineer for MetroWorks, Andreas Hamel, actually had most of the language parts of it implemented in the CodeWarrior compiler before the first proposal ever went out. And without his help, I don't know if it would have ever made it off the ground. So to this day, I remain very grateful to Andreas for his help on Move Semantics. And I had the paper all written up, the first paper, which has a 2002 date on it.

I had it basically complete, and Dave Abraham saw a copy of it and said, you know, Peter Deemoff is working this same area, except he's working on perfect forwarding. And I wonder if we can get you two guys together and kill two birds with one stone. Now, whether that was a good decision or a bad decision, people keep debating. But at any rate, that's how move semantics and perfect forwarding sort of banded together and started using the same symbol, the same R-value reference. And so Peter and David and myself, all three authored both the move semantics paper and the forwarding, uh, perfect forwarding paper. Although in all honesty, I pretty much wrote the move paper myself and Peter pretty much wrote the forwarding paper himself. Uh, but we shared authorship with each other on all three because, uh, you know, Dave helped bring us together and the world became hopefully a little bit better place. Um, I'm sorry, go ahead. Did your design, what you originally envisioned,

is that what we got in the standard? Not 100%, but I would say 99%, yes. There were a few things that changed as things progressed. And actually, there were several things added that I was not ambitious enough to even propose. But I am very happy that they did get added. For example, the original move proposal did not say that move constructors and move assignment operators were special members. The compiler would never generate them for you.

Oh, yeah, that's kind of nice. Oh, it's very nice. I love defaulting or deleting or whatever my move members. That's great. So I'm very grateful that somebody else did that work. I believe, well, I can't remember exactly who was involved in that. So I probably should not say names or I'll get them wrong. And since I'm being recorded, I can't take it back.

But I'm very grateful for everybody else that did work on the parts that I was not ambitious enough to do, did not think I could ever get it through committee, and lo and behold, we actually did get a much nicer standard in C++ 11 for everybody's help that

saw the light and said, yes, this is something we need to do, and we can make it even better. Well, parts saw the light and said, yes, this is something we need to do and we can make it even better. What parts of move semantics and R value references do you think developers are still having a hard time understanding? So for the beginner that comes into it, I think probably the hardest part is not realizing how simple it is under the hood in terms of what code gets generated.

They're imagining all this complex machinery that moves stuff around. And really, at the heart of move semantics, all it is is a compile time switch to guide overload resolution. Now, that's a mouthful because beginners won't know what the heck overload resolution is. But in essence, you're telling the compiler to pick, at compile time, a move constructor versus a copy constructor, or a move assignment versus a copy assignment. Or it doesn't even have to be one of those special movers. You're instructing the compiler to pick the R value vector pushback overload versus the L value pushback overload.

And so all move semantics is doing is instructing the compiler at compile time which function to call that's going to be optimized for R values or optimized for L values. And it's that simple. It all happens at compile time. There's no runtime magic under the hood. And I think that is probably the most difficult part for somebody first learning about move semantics. They overestimate the machinery under the hood when it's nothing but compile time magic. So I was wondering if as part of your original proposal or if it came from someone else,

the option of overloading class members on reference or rvalue reference. You mean like non-special members such as vector pushback? Yeah, no, I mean, man, I cannot recall the actual technical name for it, but at the end of a method declaration or member function declaration where you can put, Yeah, no, I mean, man, I cannot recall the actual technical name for it. But at the end of a method declaration or member function declaration where you can put a reference or an R value reference. That was actually somebody else's idea.

And it came on fairly early. I'm guessing that proposal was the 2007 timeframe or so. And I really like it. I don't use it a lot, but when I do use it, it is just the thing. Uh, and it's interesting. Yeah. It was not, not my idea. Okay. So that's, that's actually, so you said it came in maybe in the 2000 timeframe and you said you started on this on 2001. And I was going to ask if you like what was this like like basically having to work on this for 10 years before you actually saw it come into the standard but it sounds like

maybe it needed some of that time to bake it definitely needed some of that time to bake and yes it was a decade-long effort and i will never ever do it again i am very very sorry no seriously it was worth it but uh yeah it was a huge amount of work a large part of my life went into it and uh if i knew now i mean if i knew in 2002 that it would take that long i don't know whether i would have actually attempted it or not. I'm glad I didn't know. Right. So you mentioned that you were working on a proposal for Stood, the date and time library. What else do you think is really important that we should be working on

for the next version of C++? What do you think we need? Date and time, absolutely. I will, okay, so what else? I am very encouraged by the work that others are doing in the area of concepts and modules and ranges. I think that's going to, especially, I think there's a great synergy between ranges and ranges. I think that's going to, especially, I think there's a great synergy between ranges and concepts

that is really going to change in a big way the way people do C++ in the future. I'm a little bit worried about the chaos it will cause in the standard library. But as I'm no longer a standard library implementer, I'm not that worried about it. It's somebody else's problem. So I'm looking forward to the result.

It's kind of like moving. I'm currently in the middle of moving my house, and I'm really looking forward to being there, and I'm really not looking forward to the move. I feel the same way about C++. I'm looking forward to having concepts and ranges and not looking forward to the chaos that is bound to come in the path of getting there. A couple of times when I've given talks, I've pointed out that an object that has been moved from still has to have its destructor called. So you've got the shell, potentially, of an object left behind that has to be destroyed.

And inevitably, I'll have someone in the audience point out, that's why we need destructive move. And I was wondering if you had any thoughts on that. Well, actually, I'll address two points that you just said. One, in the current system, when you move from something, it generally has to do more than just be able to be destructed. It has to be a valid object in a valid state, and whatever algorithm you're using it with, it has to continue to meet all the requirements of that algorithm. For example, let's take standard sort. Standard sort says that your elements have to be move constructable, move assignable, swappable, and comparable by whatever comparison operator you're using.

Now, those requirements have to be met whether or not your element's been moved from. So it doesn't matter. Your sort algorithm, you might think it'd be pretty silly to compare a moved from object. But if legally, your standard sort implementer could say, I've got this moved from object, and I want to compare it with itself for some arcane reason, that better return false. It can't assert. It can't return true. It's got to not be less than itself. And so even though you've been moved from, you have to continue to meet these operations. Now, destructive move. The original move paper back in 2002 actually mentioned destructive move semantics.

In fact, I think I coined the term. I don't remember that term being used prior to that. And I do think destructive move semantics would be very helpful. At the time, I saw several problems with doing it that I did not know how to solve. That doesn't mean they're unsolvable problems. It just means I had enough on my plate trying to get what we had, what I was proposing, standardized, and didn't have more cycles to devote to destructive move semantics. For example, if you've got a derived type, you know, derived type with base type, et cetera, et cetera, and you want to move construct that. If you start destructively move constructing from the base, then your target gets constructed in the right order from base to derived. But your source will get destructed in the wrong order from base to derived.

Normally we destruct objects from derived to base. So that's a problem that I have yet to see a solution for. Maybe the solution is to simply say if you have a type hierarchy it simply can't be destructively moved. That would be one solution. But at any rate,

there are certainly applications that could use destructive move. Going back to vector, when it's time for vector to reallocate its buffer, it needs to move stuff from the old buffer to the new buffer, and that would be a perfect opportunity to use destructive move because what it does today is move and then destruct it, destruct the source.

And so if you can move destruct it and say, allow more elements to participate because maybe a destructive move is easier to write as noexcept, that's the more the better. So destructive move would definitely be a good thing. I would love to see it. It would not supplant our current move semantics. It would be a nice addition to it. And that would be a nice addition to it. And, you know, that'd be

great. It's not going to be me that does it. I'd be glad to consult, but I am not signing up for it. But I encourage anybody with interest to do so, to do it, and you know, knock yourself out, and I'm glad to give advice on it.

Oh, I'm curious about the work that you do at Ripple, actually, since we haven't talked about that at all. Sure. Okay, so Ripple is a financial network using digital currency, which means blockchain technology. And we are basically in the business of international bank settlements. We're trying to become the underlying financial layer upon which banks can transfer money between financial networks at a fraction of the cost that they do today and at a fraction of the time. For example, our network is currently operating at around 10 transactions per second, which is twice as fast as the theoretical maximum that Bitcoin can work at, I believe. I'm actually

talking about stuff that I don't know very well. But at any rate, our network can operate much faster than Bitcoin. And of course, if you're not using blockchain technology, settlements between financial networks these days can take days. We're not talking seconds. We're talking days, maybe a week. And of course, transferring money between financial networks, say, with conventional technology, is very expensive. Fees on the order of 10% are not unheard of or even more. Whereas the fees for using the Ripple network are on the order of a tenth of a penny or even less per transaction, no matter how much value you transfer. And so we would like to see banks utilize this technology and then pass the savings on to their customers. And so that the whole world can basically move money around in the same way that we

communicate today. You know, today email has pretty much in the Internet has transformed global communication such that it is practically free and instantaneous global worldwide. We would like to do the same thing with financial transfer, make it as easy to transfer money around the globe and as cheap as it is to communicate. I just saw an announcement that PayPal is going to be doing instant transfers instead of transfers that take multiple days. So is that the kind of thing you guys are talking about? Are you involved in that? Can you disclose if you are? I probably should not comment one way or the other on specific companies. Okay.

That's fair. I will inevitably say something that I think is public knowledge, and it won't be, or vice versa. And I don't want to take that. That is absolutely fine. That's quite all right. We are involved in having a great deal of success in spreading our technology globally. Okay. But go to our website, and whatever it says there, that's what's public knowledge.

Ripple.com. I feel like any movie that involves spies or intrigue shows someone puttishing a thumbprint and instantly transferring $10 million to the bad guy across the world. I guess it doesn't really work that way, generally speaking. I wish I had a thumbprint that valuable. Well, Howard, it's been great having you on the show today. Where can everyone go to find whatever you're working on now online? I have a GitHub page that has most of my work. Let's see, that's github.com slash Howard Hinnant, capital H twice.

Okay. I would like to make one quick correction to something i said earlier i don't know what i was thinking i said the cherokee nation in arizona and i refer i meant to refer to the navajo nation good catch okay okay well it's been great having you on the show today howard thank you for having me i really enjoyed it thanks for joining us thanks so much for listening in as we chat about C++. I'd love to hear what you think of the podcast. Please let me know if we're discussing the stuff

you're interested in. Or, if you have a suggestion for a topic, I'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. I'd also appreciate if you like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving

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