CppCast - Safe Numerics

Episode Date: March 23, 2017

Rob and Jason are joined by Robert Ramey to discuss his Safe Numerics library and the process of submitting libraries to both Boost and the C++ Standards Committee. Robert Ramey is a freelance C++ programmer for around 20 years. He has worked on a variety of applications including desktop retail applications, embedded systems on tiny micro controllers and combinations of these. For the last 10 of those years he has been active in the Boost Organization and Author and Maintainer of the Boost Serialization library Instigator of the Boost Library Incubator (www.blincubator.com) Given talks on Boost/C++ related topics at C++Now and CPPCon Written articles in print periodicals such as Software Development and ACCU Overload Of late his interest has become more focused on practical approaches to improving program correctness. This has motivated recent talks at CPP Con ( boost units library, C++ and abstract algebra) and most recently the Safe Numerics library - which has very recently been accepted as an official Boost Library. News Does const mean thread-safe? Meeting C++ Live: Multithreading with Rainer Grimm Implementation Challenge flag_set: Type-safe hard to misuse bitmask Programmers: Stop Calling Yourselves Engineers Robert Ramey @robertramey1 Robert Ramey Software Development Links Safe Numerics Library CppCon 2016: Robert Ramey "Safe Numerics Library" Boost Library Incubator Sponsors Incredibuild JetBrains

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

In this episode, we discuss whether programmers should call themselves engineers. Then we talk to Robert Ramey, author of the Boost Serialization and Safe Numerics Libraries. Robert talks to us about his Safe Numerics Library and the process of submitting libraries to Boost and the Standards Committee. Welcome to episode 94 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? I'm doing good, Rob. How are you doing?

Good. No real news for me. I think you had something to share, though, right? Yeah, I am offering a training class here in Denver on April 20th. It's going to be Understanding Object Lifetime in C++, so I thought I'd just give that a shout-out. Is it going to be with the C++ user group? Well, I will be mentioning it to my C++ users group but I don't know how many of them will come at this point. Okay. And where can people see more details about that?

I guess just on your blog, right? Well, I actually haven't put it on my blog but you can easily find it on Eventbrite or on Twitter. It's currently the pinned tweet for me on Twitter. Okay, very cool. Well, at the top of every episode, I'd like to read a piece of feedback. This week, we got an email from Alan

and he wrote in saying, great podcast guys. It's the first one I listen to when it comes out each week. I've started sharing it around at work, too, to get more of our team excited about upcoming C++ features. Maybe it'll help us upgrade past Visual Studio 2012 too. Anyway, I especially like the recent episode

with STL and all the diverse guests and topics you cover. Alan, thanks for the great feedback. I'm glad you've liked some of the recent guests. We definitely liked having STL on as well. And he definitely needs to get past Visual Studio 2012. Yeah, it seems ancient these days, doesn't it? STL on as well. And he definitely needs to get past Visual Studio 2012. Yeah.

It seems ancient these days, doesn't it? It does, yes. There's so much missing from that. Well, Alan, we should be able to hook you up with the JetBrains giveaway. Thanks again for writing in. From that, you'll get a ReSharper C++ to add in. I think they probably had Visual Studio 2012 support, even if you're not able

to upgrade. And we'd love to hear your thoughts about the show as well. You can always reach out to us on Facebook, Twitter, or email us at feedback at cpcast.com. And don't forget to leave us a review on iTunes. Joining us again today is Robert Ramey. Robert is a

freelance C++ programmer for around 20 years. He has worked on a variety of applications, including desktop retail applications, embedded systems on tiny microcontrollers, and combinations of these. For the last 10 years, he has been active in the Boost organization and is the author and maintainer

of the Boost Serialization Library, instigator of the Boost Library Incubator. He's given talks on Boost at C++ Now and CppCon and written articles and print pre-articles such as Software Development and ACCU Overload. Of late, his interest has been more focused on practical approaches to improving program correctness. This has motivated recent talks at CppCon on Boost Units Library, C++, and Abstract

Algebra, and most recently, the Safe Numerics Library, which has very recently been accepted as an official Boost library. Robert, welcome to the show. Well, thank you for having me. Congratulations on getting your library accepted as an official Boost library. Well, thank you very much. I appreciate that. Yeah, and we'll talk more about Safe Numerics later. We'll start off with a couple news articles, though.

Feel free to jump in on any of these, Robert. First one is, does const mean thread safe? And this was from, oh, I can't remember the name of the author just now. Just blanked on it. Jason? Could it be Anthony Williams? Yes, Anthony Williams, author of the C++ Concurrency book. Which we may mention, he just is publishing a second edition of that right now. Yes, I was going to mention that. He's coming out with a second edition.

Good stuff, though. And he's going over ThreadSafe and whether const makes something ThreadSafe. And this all started from a discussion, he says, on the C++ Slack. Jason, were you a part of that discussion? I was not a part of that discussion, but it is not hard to believe. So what was your take on this article? He seems to do a pretty good job of just explaining

data races, the meaning of const, and how const doesn't necessarily guarantee thread safeness, but it might be a good indicator that when you're consuming something, you shouldn't have to worry about uh threat safety when consuming right yeah and i think i was first

made aware of this uh i don't know if it was a herb sutter talk or a scott myers talk it was one or both of them perhaps have mentioned it in the past but i had never heard this rule that anthony mentions here that's uh do as in stew. Yeah. That was new for me too. I like that. Yeah. Oh,

is that again? I'm do as do as in stew. He says it's a good rule of thumb for choosing behavior for a class in C plus plus to, uh, to do as in stew with regards to thread safety. Oh, so any read operation on it is going to be thread safe,

but any write operation could introduce a race condition, essentially. Right, but of course, if it's const, you can only do reads, but then somebody else might be doing it right. Right. But what if it's a little larger structure, like an extra long or something? Are we guaranteed that that's atomic? He's saying if you're going to make something that's like that,

then you guarantee that your const operations don't modify it, essentially. Right. Well, I'm actually concerned about the possibly concurrent non-const operations. Right. We're all reading something with const, that's fine, but somebody else is twiddling it, and that doesn't guarantee that I'm not, if it's a longer thing, not guarantee I'm getting the whole thing

in a consistent patch. Right, and technically you're not guaranteed that with int either, right? It just coincidentally works out that way on most platforms right well that's that's that's actually interesting to me because then your program of course is not portable anymore but right anyway so he's saying do what int guarantees that it would do not what it coincidentally happens to do on most platforms i believe

yeah and it doesn't i don't think it and I'm not sure that it guarantees anything. That's what I'm kind of curious about. Anyway, well, I have to confess, I actually didn't read the article, so I shouldn't even be saying anything. Of course, that's never stopped me before. Well, it's definitely a good one to read, especially if you're looking into threat safety issues.

I think it is, in general, just a good best practice kind of thing to make sure that your const methods are behaving properly. Yeah. Okay, next, Meeting C++. Jens Weller recently started doing a... What's the name? It's not a podcast. It's a webcast videocast i guess something like that yeah he's so he's calling it meeting c++ live uh he just came out with the first episode uh almost two weeks ago which was with uh reneer grim who we've talked about several of his blog posts recently and this one's a little bit different from um uhppChat, which we've talked about a couple times. He's basically going through blog posts with Rainier, and they're showing code samples from the blog posts during the show. So if you want to have something a little more in-depth where you can actually look at the code, and it's not just people like us talking this is a good uh a good show for

that i thought it was an interesting approach having the screen share basically in the middle of it yeah yeah it's always good to see uh more c++ community content out there which obviously uh jens has been doing a great job at for such a long time with meeting C++. So it's good to see him doing even more. Crazy amount of stuff available today. Oh, yeah. Okay, next up is a blog post from Funathan or Unathon. And this one is an implementation challenge flag set, type safe, hard to misuse bitmask.

And here is a couple issues with using enums and bitmasks that I've never really thought of before, but he definitely had some really valid concerns about using bitmasks, and he came in with a pretty good approach on how to have something that just kind of works better

and safer than using the standard int bitmask. Did you look at this one, Robert? No, I didn't, to tell you the truth. But, you know, I've come up with that problem to the extent that all the time, and I've kind of done it all the time, so I feel I probably have already

done it like four different ways because I forget how I did it last time. But, you know, and frankly, I probably didn't look at it because I don't have that problem right now. I got really deep in other stuff. So that's kind of, I didn't really have much to say on it. I thought it looked pretty interesting.

I got to the end, and I thought of the stuff that I've been doing lately where I've cared about bitmask has been on actual hardware, and I actually care what each of these bits are that i'm setting but his enum class automatically generates the bits for you so now that's i should say that's interesting because my my scenario the one that i'm familiar with exactly what you describe that the bits the the bitmap has been given to me and i just want a way of accessing it that i don't have to go back and look at the document every time. Right.

So it's kind of a different use case. Yeah, this is more like, I guess, if you're passing multiple flags to a function or something like that. Yeah, the example he used up at the top was, you know, like doing file operations, like whether it's read or write only or read and write, something like that, which I've seen plenty of times that type of flags being set. Well, even those, you know, like if you're a Windows file system, you have those flags,

but they're given to you by the API. You can't really choose your own. Sure. Well, I think this blog post was kind of targeted at API developers. Right. Well, this is, I think this blog post was kind of targeted at, you know, API developers. Right. Well,

it's definitely a good solution. Uh, definitely worth taking a look at. And then this last article, um, is interesting. I saw this posted from the, uh,

C++ standards, Facebook group, actually. And it's titled programmers. Stop calling yourselves engineers. And it was a bit controversial, maybe. But the point the author is going at, who I guess has an engineering background, is that the title engineer is being cheapened by the tech industry, because we don't go through the same sorts of standards as, say, a mechanical engineer or a civil engineer

where they have to go through certification regularly. They need to maybe go through an apprenticeship period, and that's definitely not something that software developers go through. Right. Yeah, so what were your thoughts about this one, guys? I did read that article when it came out, and I thought it was really interesting. And I think that I got,

and maybe I didn't read it as closely as you, but I really got the impression he was making a strong comparison to civil engineers, which require a state license, that level of certification. And I don't see our profession, to the extent it is a profession, is fitting particularly well in that model because we have what we call a software engineer or a programmer spans an incredibly wide variety of activities. And so I could see you might give some guy a test on the bit fiddling involved or the minimal routing problem or whatever. But that's not really relevant to some guy who's going to develop a complicated WordPress website or vice versa.

And then the other thing is they sort of suggested that this certification applied to other engineers as well. But, I mean, I've worked for a number of electrical engineers, mechanical engineers, and there might be certification for some of that but it's a practical matter i've never had anybody uh you know ask for it and i think companies themselves feel comfortable in making their own decision and probably don't trust any certificate anyway so i think it's kind of interesting but i don't think it's a good match with our profession. You know, I actually went to school as a computer engineer, not a computer science major. And I was encouraged, I think everyone was encouraged to go through this computer engineering exam upon graduation. And I believe it was something that, you know, electrical engineers, mechanical

engineers had to do in order or were encouraged do at least, to get some jobs. But maybe it's not as required as it would be for a civil engineer. I'm not sure. Well, civil engineers building a bridge, for example. That's kind of a different level than if you're hacking a website as far as... Oh, yeah. So I get that. I'm not criticizing that that i'm just thinking that

i just don't see how that would really work for the kind of stuff you know that we do i mean all goes all the way from programming fiddling bits on microcontroller to going all the way up to c plus plus i don't know const expressiondas. It's a whole kind of different thing. And so I'm not sure how useful it would be for something which is not life-threatening. An aerospace engineer, I mean, Lockheed's got probably a thousand of them, and I doubt any of those have any special certification other than a bachelor's degree or master's degree in mechanical engineering or aerospace engineering. So the certification that the article was alluding to, but I don't think it actually mentioned, is called a professional engineer.

And as far as I know, every large, every engineering firm that has any kind of real documents that's going to have to be signed off on has at least one professional engineer on staff. And the professional engineer then is the one who's going to be held to task if something goes wrong, if the rocket blows up or whatever. So I don't know about electrical engineering firms, but I guarantee Lockheed has professional engineers working for them. Well, that may be, but I'm doubtful. Let me put it this way. If I were to apply for a job at Lockheed, I don't know that they would ask that as a requirement. No, but you would get paid more, essentially. Really? Well, if I got paid more

for taking a test, yeah, that would be great. But nobody's ever listed that as far as a job requirement that I've seen. No, the professional engineering takes, it's one of those things that's, it's almost like passing the bar or something. It takes a significant amount of time to study a separate study to actually pass it. I'm like, there are several people in my family that are engineers, and none of them have gone through the effort of becoming a professional engineer. They've all operated as engineers underneath professional engineers or, or done, you gone through the effort of becoming a professional engineer. They've all operated as engineers underneath professional engineers or done the type of engineering that doesn't require a certification, like not bridge building, like you're saying, or building.

Yeah. Okay. So that brings in a question. I mean, you kind of made my point in that even in mechanical and electrical engineering, whatever, the vast majority of people doing engineering work and call themselves engineers i don't feel are not professional engineers so i'm yeah almost certainly yeah that's certain that's that certification

i think it's interesting and i you know i've i've done some work with with making stuff that has to get approved by the FDA, and I've seen a little bit how that works there. But I don't really know that there's a good match here or that there's, you know, I'm not totally convinced, not totally sold on it. Not to say that there's not plenty of incompetence out there. But, you know, would this help? I don't know. the author brought up some valid points you know he was making a lot of comparisons i was we said to like civil engineering and obviously some horrible things can happen if a bridge fails due to some bad engineering work

and some very bad things have happened you know very recently with you know things like open ssl having uh the various uh bugs in it that cause... Or Uber self-driving cars running across cars' crosswalks. Yeah, yeah. So there's plenty of things that we as software developers can get horribly, horribly wrong with horrible, horrible consequences. I will say there seems to be a very good trend of we're doing a lot more unit testing these days than was ever done before.

But I'm not sure if there's ever going to be, you know, this type of standard in the software development industry. Well, and they are regulated. I'm sorry. Go ahead, Robert. No, I think you raise kind of a really interesting case that self-driving cars, whatever. I'm not sure certification would make a difference in these cases. I think the problem lies somewhere else, but there you go. I mean, that's kind of what I guess the discussion's about. Right. Yeah. And there are regulated industries, like you said, things that you've had to do with the FDA has to sign off on. If you're working in

medical devices or you're working in gaming, then you're working in regulated industries and have to meet certain criteria. Yeah, and there's very different sets of requirements for someone who's working in an industry like that compared to someone who's a mobile app developer or something like that or website developer. Well, my experience with a medical device was that basically it boiled down to having really a lot more formal documentation trail, which actually it wasn't all that big a burden if you were doing things in the right way that I thought you should be doing them.

But on the other hand, as a practical matter, it turns into quite a burden in a political thing. Do you really feel comfortable signing off on something that you look at and you don't really understand? It's kind of interesting, but I don't know that certification addresses that problem. I'm skeptical. Yeah. Okay, well, we mentioned it in your bio, Robert. You recently had the Safe Numerics Library accepted into Boost.

Why don't you tell us a little bit about it? What are the goals of the library? Well, you know, actually we kind of almost touched on that already. The long and the short of it is that C++ and C integer arithmetic is not guaranteed to be correct. If you add X plus Y, you have some sort of expectation that the sum is going to be equal to x plus y. And since our arithmetic is implemented on a computer, it does not exactly mirror or implement the arithmetic for integers due to things like overflows and things like that.

We write the code, but we don't really have the guarantee that it's going to do what we think it says it does when we look at it. It's that simple. And by the way, this is not C, C++ problem. Almost every modern language, with very few exceptions, suffer from this same difficulty. The languages we use, they look like algebra, but what they are is they're not algebra. They use the common algebraic notation in order to give the impression that we're doing integer arithmetic when we're actually doing computer arithmetic, and those things sometimes vary. Now, what this library does, it addresses that problem.

If you use safe integers or safe longs or whatever defines types, if you use those types, you are absolutely guaranteed you will never get a wrong answer. You might not get any answer at all, but what you won't get is an answer that's wrong without any indication, and then plow forward in your program with a wrong answer and have it ripple through to wherever it ripples. There are many documented cases where exactly this phenomenon has caused rocket crashes and all sorts of difficulties. And so this library, if you use this library,

you will be guaranteed that you will never propagate an arithmetic program, an arithmetic error into the rest of your program. How do you make that guarantee? Well, it overloads every integer operation that contains a safe integer. And then it applies a little bit more elaborate arithmetic to detect those cases where it's not going to produce a correct result. And then should that determine that it will produce an incorrect result, then depending on a selected error policy, it will either throw an interrupt or it will crash on the spot, or in some cases it may trap at compile time.

So some things can be detected even before the program is runs, and that's how it works. Now, it turns out there's this CERT website in University of Pixar. It's a big billion- deal you know funded by the government for improving computer security and they have a whole list of all the stuff that integer arithmetic arithmetic can get wrong and uh and then they have a uh a little bit of code to work around that or detect it or whatever. So basically it implements all of those little tweaks inside the overloaded integer operations so that it's as if you hand coded your whole thing in such a way that you would never get an overflow or a problem on sign change or

whatever. So the real trick is what it does is it overloads all the integer operations with, in some cases, more elaborate arithmetic and then detects the problem. A lot of cases it's not necessary. For example, if I'm adding two sign characters, C++ type promotion rules promote both of those to ints, and you can never get a problem at that point until you assign it to something uh something else which is smaller and that since the assignment

operation is also overloaded any problem will be detected there so i'm trying to give a short answer i'm not being that successful oh that's fine i think this is uh details would not be a problem i think in this interview i think our listeners would be curious how exactly you're doing these things so so you mentioned a question oh go ahead no well basically the one fundamental module in the library is called checked arithmetic and uh what it does is it implements the operations I just said, and, you know, addition, subtraction, whatever, with the checking involved. So that's one module.

Another module just overloads all the integer operations, and it calls those safe alternatives rather than the C++ primitives when necessary. So you can already kind of see how that whole thing is going to shake out right now. Okay. So you mentioned a question I was going to ask. What other languages are doing something about this?

Are languages like Rust doing anything about integer overflows or maybe some of the managed languages? Do any of them handle it better than C++ does without this library? As far as I know, no current languages today do that. I could be wrong, but I actually was inspired by a guy who made a video about JavaScript.

JavaScript does a whole different thing. It's got its own different kind of problems. But he stated that, so I'm kind of just taking his word for it. But languages that I know about generally have this problem. So you mentioned that one of the possibilities that it throws an error of some sort, you said an interrupt exception, if the arithmetic goes awry. But then you also mentioned that, you know, there's real world cases of like a rocket exploding because the integers, you know, that the arithmetic didn't work out.

But usually in that kind of scenario, you can't run software that would have exceptions because of real hard runtime guarantees. So I'm just curious, do you see where I'm going with this? Okay, and let me address this right off the bat the question everybody okay so we get to this point you can kind of see how this would work and the immediate question comes to mind wait a minute you're going to slow your whole thing down by factor x and uh that that's an unavoidable question here so I'm gonna I'm not going to avoid I'm going to explain it right here. It turns out that many times you don't have to do anything special. One case I threw out was when you have two small integers, you add them together, and C++ promotion rules will guarantee that the result is equal to the arithmetic one.

So that's fine. So a lot of times you can just tweak your types when you're informed of it, and the library has facilities for that. But you can just adjust your types to avoid a lot of these cases. And that's, at that point, you know, the number of the checking that's left is checking that you'd probably want to do anyway. And it should not be a huge performance hit. The other thing, if you, if you're in this case, like you're programming a micro microcontroller or whatever it's a little bit different i can um it does range arithmetic at compile time whenever two

multiple integers are are multiplied or added so for example if i take two sign characters i know they vary from minus 128 to 127. If I multiply those together, then I know they'll fit into an int. On the other hand, if I'm assigning that to another character, I know I'm going to have a problem. What I can do is I can pick an error policy that traps a compile time if it's ever possible for it to overflow. So when I compile my program, it will fail at every operation which can possibly fail. At that point, I tweak my types or whatever to avoid the problem, and finally I get the thing to compile.

And then I know henceforth and forever, it will never produce invalid arithmetic. And it will never throw an exception. Does that make sense? Do you need a little expansion on that? I do have one remaining question. That does make sense. But you're going to reach a limit, right? Like if you're multiplying two 64-bit integers what happens now well the thing is that if if if they're 64-bit integers which hold 64-bit values you're sol you know if you

but we meant what happens when you initialize your variables uh you put in there uh you can there's a particular type called a safe range when you say, this particular type is the rocket thrust or whatever. And I know that that can never be a value greater than, you know, a billion pounds or whatever. And so if I include ranges in some of these variables, then I know that the range is calculated at compile time based on the expression. And then I can know for a fact that even though I'm using 64-bit integers, the value in particular does not exceed the 64-bit integer. In other words, we keep track of the maximum and minimum values at compile time independent of what the type can actually hold. So we do range arithmetic on the ranges of the variables at compile time in order to know that we won't have these problems.

Okay. So that's a third component of the library, which is integer range arithmetic and addressed at compile time. And a compile time range arithmetic library, if you want to call it, a sub library. So that's the kind of the third component. Okay. Okay. It's a bit to swallow. I know it makes a lot of sense to me. But, you know, there you go. You know, I've been sticking my hand in it for a long time. So, but the long and the short of it is if you use these types, then you will get either an exception. If the exception is not good enough, you can select an error policy which will flag all the parts you need to tweak so that you'll never have a problem and

you'll never get an exception do you see um a particular target market for this library or are you hoping any c++ library or application developer might be able to get use out of it well you know i i really it really addresses that problem whereas integer arithmetic is is is not going to you can't you don't know that it's going to give you the right answer. And I envision self-driving cars. I envision rocket ships. I envision anything. It's very easy to use. And one case study I'm working on is a stepper motor microcontroller. And I just imported the code and I tweaked the types, and bingo, I got an exception in one particular case from the demo. And so I see it as being useful.

It doesn't require you to really change your code. If you just took your code and said, I've taken all the ints, I'm going to replace them with a safe int, and then I build it and see what happens immediately. And then I run my tests with that, then we'll see what happens. John Maddock, who is, you know, one of the, how should I say, the all-stars of Boost, I browbeat him into taking a look at it. And he said, I'm not going to read the manual, I'm going to try something different. He just said, I'm going to look at it.

And then he took one of, he has the multi-precision integer library, which is like really complicated. And he took one of his demos or a couple of his demos, and he just changed the ins to the safe version. And then he ran it and worked like it's supposed to. He did find on GCC it took about 20CC it took about 20% to the execution time. And also with Clang, about 20% to the execution time. And with Visual Studio, it did add, I think it doubled the execution time.

So there's some work to do there. But, you know, there you go. So I believe that this is going to be a real practical method for being able to generate code that we know is correct. That's my goal. I am curious

if there's any classes of errors that it cannot detect. And I tell you why. Because there's only really seven operations. You know, addition,

subtraction, multiplication, division, modulus, and then there's a couple ones a little more oddball. Shift right, shift left. And all other things are compositions of those. So I can enumerate every case. And, uh, that's what I've done.

And I'm not really alone on this. As I say, all those operations are described in detail in the, in the cert manual. And, uh, here's the book, Secure Coding in C and C++. It's a thick book. If you go to – It's a thick book, yes. No, it's not. I got – here's the C++ book.

That's a lot thicker. And then you got to look at the C++ standard. It's 1,500 pages. And growing. Yeah, and no end in sight. So I do believe that this is – I do believe that I will be able to say that there is no arithmetic error that this will not detect. And that's my goal. I believe it will be reached.

And I'm confident it will be reached because there's a finite set of operations. Of course, when you start composing them, adding together and then multiplying, the whole thing starts propagating in more complex expressions. But you don't have to deal with that. You just deal with them one binary operation at a time.

And you know that the composition is correct. I wanted to interrupt this discussion for just a moment to bring you a word from our sponsors. IncrediBuild dramatically reduces compilation and development times with unique process virtualization technology. The tech transforms your computer network into a virtual supercomputer and lets each workstation use hundreds of vital cores across the network. Use IncrediBuild to accelerate much more

than just C++ compilations, speed up your unit tests, run more development cycles, and scale your development to the cloud to unleash unreal speeds. Join more than 100,000 users to save hundreds of monthly developer hours using existing hardware. IncrediBuild is already integrated

into Visual Studio 2017. Just make sure to check. IncrediBuild is already integrated into Visual Studio 2017. Just make sure to check the IncrediBuild box in the C++ workload in the Visual Studio 2017 setup. So you mentioned C++ standards there, and you actually submitted this library both to Boost and to the C++ standards process. Is it still moving through the standards process? And how different are the two versions of the library for Boost and the standard? Well, when I first made it, you know, this thing started out simple like everything else.

And then, of course, some wise guy says, well, you know, it's going to be really slow. So then I have to address that. And that means that I have to go into the compile time range propagation. And now it's not simple anymore. And then, well, but then I need ranges to – I mean, Jason already asked the questions. One after the other, and bingo, it means another feature. So I had interest in – and I think it's important, I think in Beeman, Beeman Dawes said this is something that should be in the standard library. I kind of believed him on that.

I gave a little talk about it at CPPCon, and Hans Bohm was in the audience. We talked a little bit about it. But I had about a year ago, and I made a simplified version, a feature without all the bells and whistles, and made a proposal to the standards committee. And I made a Skype presentation at the standards committee. And I have to say, the response I felt was not enthusiastic enough for my taste. And besides that, it was a cut-down version, whatever. And so then I really decided, in order to flog this thing through, I would have to go to all these meetings for a couple of years and no guarantee of success.

And I found it very disheartening and not something I wanted to do so I decided to really kind of spin a little bit and invest all my effort in getting this into Boost and make it available now. So that's kind of interesting little maybe story about what the future of Boost is versus the future of the standard library. They're kind of different things, and I think that each one is more suitable for some things and the other is more suitable for the other things. The committee is a big committee, and it is a committee, and it's really hard for a committee to design something that's really complicated. I don't think that including stuff,

something like ASIO into the standard is really going to be a super great idea myself because it's going to create a huge amount of effort. And for what? I mean, the code's already working. People are already using it. So they could spend their time in fixing other stuff, which bugs me. That's an interesting particular library that you bring up, because I imagine its addition to the standard library will not be small. It'll add probably 100 pages. I'm just throwing a number out there because I know it's a big library. Right, and we're looking at another three years to get it. What's the point? And by the way, do you think they're going to go through

the whole thing and then write all this specifications? And it's not code, it's just specifications. And then the individual vendors are going to say, oh, okay, on the specification, we're going to make our own implementation of ASIO. Let's assuming they did that, which to me is like unbelievable. What would be the point? I mean, where are you going to hire three or four guys, you know, work six months or a year to generate something which is you can just download? I'm not getting it. That's, you know, that's it. I'm just sorry. I'm not getting it that's uh you know that's it i'm just sorry i'm not seeing it from an economic point of view if they got if they got those resources

have them give me a call i'll give them some stuff to do i mean i guess the point is to get it in the standard though where you know someone who maybe can't use boost will be able to use something like asio well if it's in the standard okay it's more universal that's true but as i say i as i say i think that there's other things that they could probably uh spend their time on like uh symbol visibility getting that squared away between all the compilers, which would help me a lot. But, you know, whatever. My thing on the standards thing, I stuck my toe in the water.

You know, I couldn't get excited about it. I do like Boost. It gives me a chance to put something out there that's far out. If I can get it to the point where I can get enough people interested, I got reviews from John Maddock, Vicente Botet, Stephen Watanabe. He wrote a thing which must have been 20 pages long. And he went through the thing in incredible detail. This kid or this guy has just got an incredible C++ brain. You know, I don't think I'm getting anything like that from the committee. And Peter Demoff chimed in. I mean, a lot of stuff, a number of stuff he wrote, the committee just accepted, period, without even, you know, just accepted it as is.

So anyway, at least as far as I'm concerned, Boost is a better vehicle for what I want to do. I asked a question about the future of Boost to Bjorn Sustrup at CPPCon last time. He said, you know, Boost has done a lot, yada, yada, yada. But, you know, a lot of this stuff is really too complicated. And I think he's right. I mean, I think this is too complicated for the committee. I think ASIO is too complicated for the committee. So I'm kind of on board with him here, but we're not reaching the same conclusion.

But there we are. I think it's an interesting case what the future C++ is, and I think how it's going to grow, it's tough. The low-hanging fruit's been taken. I'm just thinking the standards thing's worked out really well. But on the other hand, I think things have to take a little bit different trajectory in the future. I'm the only person I know that expounds that opinion. So I guess the short answer is you do not expect it to end up in the standard then if if somebody wants to put it in there that'd be great but uh you know uh but i'm not i'm not gonna spend a lot of time flogging it myself let me put it that way uh who knows you know

what concepts you know how long does it take between that's the time the idea first comes up and the time it goes into the standard? Look, 15 years? Yeah. I'm 69 years old. Frankly, I'm not going to wait on that. You're not looking forward to being 84 years old and trying out concepts, you're saying, at this point? No, I'm not looking forward to being 84 years old and seeing safe numerics in the standard. Right, right.

Because if I have to wait until I'm 84 you know i can't wait that long i want and i i honestly believe i'm looking at that people making flying cars i mean they probably only have i don't know how few of them they not flying car well flying car is even better example i'm still waiting for my flying car it's been 17 years since I was promised one. You're talking about self-driving cars? And then it's going to be written with integer arithmetic? I don't know. That's a good point.

So when we had you on last time, which was like two years ago, we were talking about the Boost Incubator. How's that going? Well, I'm, you know, it's, I'm not, how should I say, I don't want to say this. It hasn't really reached and accomplished everything I hoped it would. It hasn't been a total fiasco either. So, you know, I'm a little bit ambivalent. There's, I think, 40 some odd libraries in there or 40 between 40 and 50, like five of them have become members of Boost.

So in that sense, it's a success. I had hoped that it would generate reviews in advance of the formal review. The review queue process in Boost is, you know, pretty long, and it's kind of arduous, and I had hoped that this would, by providing a rating system and this and that, it would help the library authors get more feedback, and before they, it really went into Boost, and so in that sense, I've been disappointed, as I say, but there's been a lot of good submissions, so that's positive. So, you know, it's a two-edged sword. I think I'm not – it hasn't realized everything I'd hoped for, but as I say, I think that it's still done some good.

It also gave me an opportunity to flog my ideas about how a library should be developed. You know, I have – my view is that library documentation in Boost and everywhere else is really awful. And I think that if the library developer develops the documentation in parallel with his library, it's a lot less painful, arduous task, and the library comes out better. So I have my particular ideas, and I flog those ideas, but nobody's complained about that. So I guess it's okay. But, you know, that's where that is. It's kind of, people still add libraries to it. I'm not flogging as much as I had, but, you know, hope springs eternal. Maybe it gets reconfigured a little bit and really takes off, which I would

like to see. But a very interesting little tidbit is, you know, if you look around for libraries, it turns out that what I require is I don't take, I accept everything that meets certain minimum requirements. I don't make a judgment on the value of the library itself or in any way. I just say it has to meet certain minimum requirements. And that means it has to kind of look like a Boost library. It has to have tests, and it has to have documentation. And if you look around the net, thousands of libraries in C++ code, those three requirements will eliminate 99.9% of anybody who thinks he's got a cool piece of code. Having a cool piece of code is not the same as having a library which you can think about submitting to Boost. But you did put your own library through the incubator process, right?

I did. I put it in there, and I got one review from this Polish guy whose name I can't pronounce. It starts with an A. And he raised exactly the questions you did. He said, well, I'm not even sure this is really useful. Why would anybody want to do this? And by the way, isn't going to slow things down.

And so it became apparent to me that I had to address this. I couldn't just say there's no point in writing a program that's going to give the wrong answer. If you're really worried about speed and you don't care if it gives the right answer, you might as well just have one statement program that returns the wrong answer. But that argument didn't fly with a lot of people. So, you know, and then he was the review manager. He was also incredibly thorough. The Boost review process is very excruciating.

And you get a few people, not as many as you'd hope, but they're extremely insightful. And it's kind of like defending your thesis. And so that's, but it really makes you a better programmer so I wish more people would consider looking at the the incubator and thinking about taking their coolest bit of code and making it looking really professional and putting it up there right okay well is safe numerics in the the most recent boost release or is it going to be in the next one? No, it just got accepted like a week ago.

I thought, you know, I spent a lot of effort. I've already been through the serialization boost review twice because it flunked the first time. So it's like really bad to go through it once. It's like awful for it to go a second time. And so I said, oh, okay, this time I know

what I'm doing. And I spent a lot of effort trying to make it as perfect as I thought it would be. And then I submitted it. And then I got the first review from Steve Watanabe, who, by the way, shameless plug, he's looking for a job. So if anybody wants a C++ guru of the extremely highest caliber, that's the guy. He's a very smart guy, and everyone speaks very highly of him. If you've seen him work with your code, it's humbling. And then it became apparent, you know, they pointed out some really fundamental bugs, which are fixable, but not trivial to fix. And that's what I'm fixing. So that's going to take, you know, probably a couple months before I think this is ready again. That's the way it is.

So it was accepted pending a couple fixes? Yeah, more than a couple. Okay. Okay. Well, and it's more than a couple. Okay. Okay. Well, and it's more than that. You know, then they want, you know, hey, how about a case study here, and what about constexpr, and then you have to

go into a whole bunch of stuff. Oh, you know, you're just rolling your eyes. Anyway. Oh, and what about the Microsoft compiler? Well, I don't have one, yeah, but you know, it doesn't work there, and it doesn't include files. It just goes, it's really, if I strung work there, and it doesn't include files. It just goes. It's really, if I strung it out, it would probably be about 10 pages long. Wow.

Okay. I'm glad to hear they're thinking about constexpr, though. Well, constexpr is a very interesting thing. It's a big, big, without constexpr, we would not have this, because that's the key which is necessary for propagating the range arithmetic.'s compiled time that's much handier than nested recursive oh no i i looked at that and no no no it was just not uh it was not well and the worst part is that some of the the that range stuff has to be done at runtime also so that means it would have to do it twice. Right. One time worse than the other.

No, no. It was C++14, constexpr, the stuff they're adding in. We're going to see a lot of fallout from that, as we already have from C++11. We wouldn't have HANA without C++11. Or probably C++ 14 but when they when we really add something to the standard i noticed that all of a sudden you know boost gets a bunch more submissions interesting it was it was before at the end of like 2010 before c++ 11 it was it seemed like boost was kind of winding down and you know they talked about this and that. But that talk doesn't occur anymore because now the newer C++ has created so many opportunities for new stuff. And we're seeing quite, well, we see this, for example, and HANA and other stuff too.

Are people going back and applying constexpr and noexcept and and that those sort of things to older boost libraries at this point i doubt it um i i don't think if you've got something working on c++ 03 there's really i mean what i did in the serialization library is i made a few tweaks so that it would work it would it would exploit the C++11 stuff if available. But I don't want to go back actually and spend more time on the serialization library other than the minimal fixes I have to do to keep it running. And I think everybody else would feel the same way. I'd rather work on something new.

And what's the economic benefit of going back? And if I went back into the serialization library of C++14, the amount of code might drop by half or two-thirds. But, you know, the machine code generated would probably be the same. I don't know how much difference it would really make. Maybe, yeah. Okay, Robert, well, it's been great having you on the show again. Where can people find you online or find more information about the Safe Numerics Library? Check its progress.

Well, you could Google Safe Numerics, and you can Google Robert Ramey, and you can also go to my website, which is rrsd.com. That's robertrameysoftwaredevelopment.com. I have a Twitter handle, which is robertramy1. I've only started using Twitter now because I wasn't sure it was going to last. And what else? That's about it. I'm on the boost mailing list pretty regularly, ranting and stuff like that. And, um, there, and then whatever, I, I'm not sure anybody who wants to find me can find me and anybody who doesn't,

they might find me anyway. Okay. Well, it's been great having you on the show again today, Robert. Okay. Well, I'm hope,

hope you had fun. Thanks for joining us. Bye. 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 RobWIrving and Jason at Leftkiss on CPP cast on Twitter, you can also follow me at Rob W Irving and Jason at left kiss on Twitter. And of course you can find all that info and the show notes on the podcast website at cppcast.com.

Theme music for this episode is provided by podcast themes.com.