CppCast - Bounded Integers

Episode Date: August 10, 2015

Rob and Jason are joined by David Stone to discuss his bounded integer library. David Stone has spoken at C++Now and Meeting C++. He is the author of the bounded::integer library: http://doublewise.net/c++/bounded/ and has a special interest in compile-time code generation and error checking, as well as machine learning. He owns DoubleWise C++ Consulting, providing on-site training with an emphasis on performance and correctness. He also works at Markit integrating real-time financial data. He once wrote an optimizing compiler that solved the halting problem, and is just waiting for it to finish compiling his program. News What do you want to see in VS2015 Update 1 New Clion 1.1 EAP CppCon 2015 Program Additions David Stone David Stone on StackOverflow doublewise.net Links C++ Bounded Integer Library C++Now 2014 - Removing Undefined behavior from integer operations Meeting C++ 2014 - Writing robust code C++Now 2015 - Functions want to be free C++ Truths: Want speed? Use constexpr meta-programming!

This episode of CppCast is sponsored by JetBrains, maker of excellent C++ developer tools including CLion, ReSharper for C++, and AppCode. Start your free evaluation today at jetbrains.com slash cppcast dash cpp. And by CppCon, the annual week-long face-to-face gathering for the entire C++ community. The 2015 program is now online. Get your tickets today. Episode 22 of CppCast with guest David Stone recorded August 10th, 2015. In this episode, we discuss upcoming changes in two C++ IDEs. Then we'll interview David Stone from Double Wise Consulting. David will tell us about his bounded integer library and why you may want to use it to avoid undefined behavior. Welcome to episode 22 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 tonight? I'm doing all right, Rob. Is your move all settled in and done with? All settled in. My kids are here now. The house is completely unpacked. And now we're just trying to find a new normalcy now that we're moved from New Jersey to North Carolina. So it should be an exciting few weeks getting to know everything around here. But yeah, we're here. I imagine it will be exciting. Yeah, definitely should be. There's a lot to do around here. So that's good. Cool. So at the start of every episode, I like to read a piece of feedback.

This episode, Keith wrote in, and he writes in, Thanks, guys, for the great podcast. A few months ago, I moved into a position as a C++ developer. After seven years as a.NET developer, your podcast has been a great help in getting me oriented in the world of C++. Books and documentation are good for understanding the specifics of the language itself, but it's nice to be able to listen to discussions about the broader world of C++ and what others are working on.

Keep up the great work. Keith, thanks so much for the feedback, and welcome to the world of C++ from.NET land. I'm glad you're enjoying the show. And yeah, thanks for listening. We'd love to hear your thoughts about the show. You can always email us at feedback at cppcast.com Follow us on Twitter at twitter.com

slash cppcast or like us on Facebook at facebook.com slash cppcast and you can always review us on iTunes which helps us find new listeners. We really appreciate that. Joining us tonight is David Stone. David has spoken at C++ Now and Meeting C++. He's the author of the Bounded Integer Library and has a special interest in compile time,

code generation, and error checking, as well as machine learning. He owns Doublewise C++ Consulting, providing on-site training with an emphasis on performance and correctness. He also works at Market, integrating real-time financial data. He once wrote an optimizing compiler that solved the halting problem, and is just waiting for it to finish compiling his program. David, welcome to the show. Thanks for having me.

So do you have an estimate for how much longer that compilation is going to take? Yeah, I'm going to have to say two weeks. Okay. That's my standard estimate. Sounds great. Okay, so we have a couple pieces of news before we get into the interview with David. The first one I have is STL got on Reddit and was asking what people want to see

in VS 2015 Update 1. And it's always great to see that they're really looking for feedback on what C++ developers want to see the most. Is there anything you wanted to call out in this discussion, Jason? I saw that a lot of people are asking about Sfinay and extended const

expert support. At this point there's 153 comments on there. It's quite the discussion to just read through and just get an idea for the overall state of Visual Studio today and it surprises me how people still call out so when are you going to finish the C99 preprocessor support? Yeah, I don't know how that is not done still. How about you, David? Is there anything else you want to comment on here? Yeah, like I kind of agree with those would be the two main things that are preventing

me from really being able to write modern C++ code on Windows with Visual Studio. The extended constexpr being the number one and then expression Sphenae being number two. But the other thing that is kind of really important to me, and it's less of, I guess, a new feature than a type of improvement, is more just generally the performance of the standard library and the optimizer. Like when we at my company at market, when we've switched from compiling programs with visual studio to compiling them with a GCC, even under like MinGW, for instance,

we see pretty significant performance gains, like two to three times faster. Oh, wow. So we're moving almost entirely away from Windows for any high-performance code because of that. I have also noticed Visual Studio is not as fast as GCC, but I have noticed it does compile faster, so that's something.

Have you tried playing around with it? Yeah faster, so that's something. Yeah, but then you have to play for that. You're worried about your compilation speed. Even with some of the optimization flags, you can't get any better performance out of Visual Studio Compiler? No, so to give you an example, we had a particular program once. We ran it in Visual Studio with the optimize for speed flags. Everything turned up to the max.

And it took maybe, let's say, 20 seconds to complete a particular task. We compiled the same program in GCC under MinGW. And with no optimizations turned on, it finished in like 15 seconds, just because the standard library, which we make heavy use of, is much more optimal in just how it executes things. When we turn on optimizations, we can process, say, a particular application

on a particular hardware can do maybe 800,000 messages per second, but when we port it over to compiling GCC in release mode under Linux, so it's not exactly an apples-to-apples comparison. We're also changing the OS here. But when we do that, instead of 800,000 messages per second processed with this application on this particular hardware, we get 4 million. Wow.

It's a huge gain for us. Well, it does sound like there has been a lot of work on the STL and its performance. Reading comments from STL about the STL for Visual Studio 2015, so I don't know, maybe it's made some difference. Yes, a lot of these tests we ran on Visual Studio 2012, but I've kind of been keeping up with it,

and 2015 is better, but still not as good as GCC's optimizer. Okay, that's interesting. One thing STL does mention here, which is worth calling out, is that Expression Sfinet, they have promised, will be delivered into 2015 with one of the updates. They're just not saying at this point whether it'll be update 1 or update 4 or so.

But sometime over the next year you would presume it should be coming out. So that's good. Is there any word of when the extended constexpr is going to be in Visual Studio? I haven't heard anything about that. I'm not sure if they promised that one at all yet.

Jason, do you remember seeing that in any of these comments? I have not, yeah. I don't know either. I'm doing a quick search to see if I see anything. Yeah, it does look like the work is related because it all has to do with improving the parsing. So hopefully after they do expression SfinA, they'll be a lot closer to extended constexpr. But I'm just guessing. I don't know much about it.

There's a comment from STL saying, they've explained to me that fixing this is blocked in on C1XXxx getting a proper parse tree related to work for express and spin a extended constexpr etc so it comes down to the parser yeah okay the next article is uh sea lion 1.1 early access build is now available for trying out, and the article goes over some of the improvements they've made. Some of the changes were that more files appear under the project root of your IDE. What else is here? Looks like they said their parsing parser has been updated a lot also. Right, right. So I know a lot of people are probably playing around with CLion. It's definitely grown a lot with the early access builds, and it's great that they're continuing that program now with 1.1.

So if you're using 1.0, it's definitely worth trying out the new builds and seeing if it is getting better and better, which I think it will be. David, have you tried out C-Line? No, I haven't. I guess I'm more of an old-school kind of programmer. My IDE is normally like a terminal window and a text editor. So I haven't quite found the time to test that out yet. Okay, I don't think I could live without an IDE of some kind.

Well, and there we go. You know, we've had people asking us about the developer setup of our interviewees, and that's the first comment I believe we've gotten about that. Yeah. I also just use Vim, basically. That's my IDE. Can't do it. Okay, the next article I have here is

CppCon 2015 Program Editions. Last week, we looked over the schedule a bit when we were talking with James McNellis, and one thing I kind of noticed is it did seem like there weren't many keynotes, and it looks like they're adding some more speakers.

Herb Sutter will be presenting on writing good C++14, and Chandler Carruth will be talking about C++ tuning. So it's good to see some more big-name speakers on the list. And if you notice, Herb's talk is going to dovetail off of Strewstrup's keynote that's just about guaranteed to be about three hours of good watching for all of us

whether you're at the show or if you watch it later yeah definitely and then they're also saying there's going to be a grill the committee panel and what is this? Who's Sumant Tambay? I'm not sure if I'm familiar with him.

I don't know the name either. Yeah, I believe he's the owner of, it's called like a C++ Next or something, I believe. Okay. He has a fairly popular website. Okay, and he'll be doing a talk on reactive stream processing in industrial IoT using DDS and RxCPP. CPP Truths is what it is. Okay. Oh, that sounds kind of familiar. I think you wrote the Wants to be Passed by Value article.

Okay. If you've heard of that one. I think that was him. I'm checking right now, actually. Oh, yeah, FunWithLamb does. That's the articles that I'm familiar with. Yes, okay. Okay, I'm not sure if I've read that article. I'll have to look for it.

Well, David, we have a... I don't know what I was going to say there. You've been a regular speaker at C++ conferences for the last couple of years. Are there any particular topics you wanted to focus on today? Yeah, so I'd hopefully be able to talk a little bit about my integer library that is kind of what I've been spending a lot of my time on lately. And this past year at C++ Now,

I also gave a presentation on when to use member functions and free functions, and that might be a little interesting to go over. Okay. Do you want to start with going over the bounded integer library? Yeah, that sounds good. So basically the goal of the library is I guess the problem it's trying to address is that the built-in integer types

in C and C++ so like int, long, unsigned they are unsafe to use and it is incredibly difficult to use them in a safe way. So, like, for instance, it's undefined behavior if you have signed integer overflow. So you add two numbers, if they're signed values, and the sum of them is larger than can be held in it, you just get undefined behavior.

And the compiler will optimize, assuming that basically that code never gets reached and so you can get really weird behavior anytime you get undefined behavior like it's a really bad thing to to ever encounter that and unsigned integers instead of undefined behavior they just wrap around um so that's not always what people expect or what they want like you expect expect that, you know, if A and B are both greater than zero and you add them, the result is greater than either one of them. But in C++, that's not necessarily true. So what my library does is, to give an example, you can specify the exact bounds of a given type. So you could say, you know, A is an integer between 0 and 10,

and B is an integer between 5 and 15. And when you add them, the library generates a new type for you that says, oh, the result of this is an integer between 5 and 15. And it does all of this at compile time, and it tracks these bounds at compile time and it makes sure that no matter what you do you never end up with an out-of-bounds integer you never have integer overflow or wrap around or anything like that and all the checks are done at compile time there's no runtime overhead unless you specifically ask for say throw an

exception if i assign an out-of-bounds value, like certain things that essentially can't be checked at compile time. So it makes pretty heavy use of constexpr and type deduction to really use the full power of the library. So you said it's all done, like you were just saying it's all done at compile time as much as possible. So if you assign from an unbounded integer, then there's no way for it to check that at compile time, right?

Well, it kind of depends. So let's say you're using the header C standard int, and you're using a fixed width integer type int8t. Okay. So on most systems, that's going to be between negative 128 and positive 127. So if I have a bounded integer that can contain all of those values, then there

is no runtime check. It looks at what's the minimum possible value of this other integer, and the maximum possible value. And if they're entirely in range, then it's an implicit conversion and there's no runtime checks. If there's an overlap, then it's an implicit conversion and there's no runtime checks. If there is an overlap, then it's an explicit conversion and there is a runtime check unless you specifically give your

integer the policy that says never do a runtime check. And if there is no overlap at all, then it's a compile time error. So like if I have a bounded integer between 200 and 300, you can't assign an int8t to that because there's no possible way that it's actually within the range. Oh, interesting. Okay. I want to wrap this discussion for just a minute to bring you a word from our sponsor JetBrains. C++ is on a comeback lately, isn't it? This language has been around for so long, yet it's hard to find a good development tool for it. Luckily, our good friends at JetBrains have just released a new IDE for cross-platform development in C++, and we thought you should know about it. This IDE is called CLion, and it's compatible with Linux, OS X, and Windows.

It relies on the well-known CMake build system and offers lots of goodies and smartness that can make your life a lot easier. CLion natively supports C and C++, including the C++11 standard, libc++, and Boost. But that's not all. Editing CMake files gets a lot easier with CLion, thanks to completion for commands and file names and automatic updating of CMake files. With its in-depth understanding of C and C++ code, CLion brings you smart, relevant code completion. It also gives you full coding assistance, like customizable coding styles, key maps,

and project views. You can instantly navigate to a simple declaration or usages, too. And whenever you use CLion's code refactorings, you can be sure your changes are applied safely throughout the whole codebase. When it comes to version control systems, the IDE supports Subversion, Git, GitHub, Mercurial, CVS, Perforce via a plugin, and TFS, with a unified interface for all of those. It even has a built-in terminal where you can run any command without leaving the IDE, locally or remotely, using the SSH protocol. A powerful language needs powerful developer tools. With CLion, now you've got those. Download the trial version at jetbrains.com slash cppcast dash clion. And if you are a student or developing

an open source project, use CLion for free, courtesy of JetBrains. So if I have an existing source code base, and I want to replace my integer types with bounded integer types, how much work would be involved in that process? So when I have done this with my own code, I kind of find it's helpful to start with kind of internal calculations within a function and then move to function parameters and then finally function returns. start with kind of internal calculations within a function, and then move to function parameters, and then finally function returns.

So basically anything where you don't have to worry about other interfaces. You can just do a drop-in replacement, and with a lot of things it'll work. And then you kind of go out from there. There is kind of a rough part in the middle where once you start using it you want to keep using it because you get to keep all of the compile time uh uh checking in there and the safety but like it it's really difficult to make it um able to like interoperate with the built-in integers in a safe way. You can't have

an implicit conversion operator. You have to have an explicit conversion operator. Otherwise, all of the functions that you try to delete will still be there because it'll first convert to a built-in integer type and then do the operation. It's definitely not like

do it in an hour and your whole code base is converted with a regular expression kind of thing like it does take a bit of work to get there uh but i feel that you know once you actually do get there it's pretty easy to to stay there that's interesting so is it being used live uh in any code today um so it is currently being used in uh a few of my personal projects um i have a program that uh plays the uh online uh video game pokemon and it uh it's a it plays other humans online and does pretty well um it uh it's also been implemented in a, there's a fixed point library by Izvakov, that's his last name. And he implemented this compile time arithmetic fixed point library

and runtime arithmetic where it can accept any sort of integer type, either the built-in integer type or my integer type. Other than that, since it's a fairly new library, it's still under pretty active development. It's more, I guess, hopefully maybe early next year it'll be starting to get used in more production systems. I'm curious about the online Pokemon player. Is it like a Pokemon AI?

Yes. Yes, it is. It was actually the project that I did first that kind of got me into programming. I started it in high school. And yeah, it logs online. It's actually a fairly large group of logs online. It's actually a fairly large group of people online. There's tournaments that you can

go to that pay out prizes and trips around the world and various things. So it can log on and it generates teams. It learns from its mistakes and gets better over time and plays against people. Wow.

Okay, so this is the code for the actual website that you're talking about. It is a program that logs into servers and plays on there. Okay. Pretends to be a human, in other words. Yes. That's pretty neat. So back to your library though um have you done any

uh any metrics to see like what kind of runtime or compile time impact using your bounded integers has uh yes so in terms of the compile time performance, it's not really a huge or even really noticeable hit. Like, I haven't noticed any difference in the compile times. a little bit is I have a test that creates a multi-dimensional array of like 5,000 of them and that takes somewhere between around 10 seconds or so to compile. Everything else that like all my unit tests compile like pretty much instantly and the reason for that is I'm taking advantage of the C++14 and in some cases C++17 features that allow me to directly express to the compiler exactly what it is I'm trying to do. So rather than like the C++03 kind of metaming stuff like Fusion and MPL, where you use combinations of the preprocessor and templates

and generate thousands of instantiations of things, I can just use a variadic template, and that significantly improves your compile time. That brings me to another question that I had then it sounds like this could potentially be a pretty challenging library to implement have you come across any i mean what was your biggest challenge or you know i think that stretched the most yeah so one of my biggest challenges is not crashing the compiler. Okay. So currently it can only get compiled on Clang 3.5 or 3.6,

GCC 5.2 and 5.1, according to their little table of supported features, support everything that my library uses, but I get internal compiler errors um i reported uh some bugs in 5.1 which they fixed and then in uh in 5.2 but then that exposed another bug that i'm working on reporting back to them now um just because i'm i'm i guess flexing so many parts of the compiler that are fairly new, it's, it can be kind of difficult to, in some cases, to even be able to work around this bug. Like I kind of get to the point where I say, okay, you know, let me let me reduce this bug. Okay, I found the problem. So I work around

it. And that's an extra 100 lines of code in there to, to work around it. So then I kind of have to make, you know, do I want to write this more complex code or just wait until the next version? And I typically just wait until the next version because one of my goals with this is to use it as a way to kind of push compilers forward and make sure that, you know, I'm testing them out and reporting bugs back to them and not ending up with you know like each compromise you make on its own seems reasonable but then you do that 50 times and now you have a program that's 10 times larger than it should be right so i take it oh yeah no you didn't finish

yes that would be one of the the main problems I've run into, or difficulties, I guess. But I guess on the other side of it, like in terms of the implementation side of it, like as I mentioned, the integer arithmetic in C and C++ are really difficult to get correct. And in some parts of my program, or in my library rather, I can't use my library to implement it because that would cause a circular dependency. So then I have to very carefully write my code by hand, essentially re-implementing a small part of the library. For instance, when I write the modulus operator, the remainder operator, that's probably been the most challenging piece of code in the library, just trying to get that correct and able to compile with...

Like, before working on this library, I never considered the compile time algorithmic complexity of my algorithms. But when I was writing the modulus operator, I had to make sure that I had a constant time solution to calculating the bounds of the result of the modulus operator. So I take it that there's no chance for Visual Studio support until the extended constexpr support comes in? Correct. Extended constexpr and expressions CNA.

In theory, I could work around the lack of variable templates, but in practice, I feel like by the time we get there, we're just going to have good enough clang support on Windows that I would just recommend people go that route. I have not had the opportunity to work on any code that is pushing C++

that much yet. For sure. Yeah, it's a lot of fun. And really kind of make sure that you really know what the language is doing and what you're allowed to do. So when I go to C++ now, a lot of times I'll have a list of things that I want to ask people or bring up and try to figure out what exactly does the standard say here

and what should the standard say here, because there's a lot of people who are on the standardization committee who go there who know about the defect resolutions and all that sort of thing. Out of curiosity, you started off by saying that C++ has undefined behavior when you add up two integers that would go over the size of integer max. What do some of the other languages you're familiar with do in that sort of situation? Do they throw exceptions or would they produce a compiler or a runtime error? Yeah, so it kind of depends. In C++, we only have the concept of bounded integers built into the library.

Like all of our integer types are bounded in the sense that they have a minimum and a maximum that are determined at compile time. You can use some libraries like the GNU multi-precision library to add arbitrary sized integer support. And you have languages like, for instance, Haskell has a similar sort of distinction between this bounded integer and an arbitrary sized integer. So the question of what other languages do a lot of times depends on which integer type you're using in their language. So if you have an arbitrarily sized integer, an integer that can get as big as you want and doesn't have any fixed bounds at compile time,

then there is no such thing as overflow. At kind of the other extreme of that would be the Ada programming language, where I actually drew a lot of my inspiration from. Ada was designed to be a highly reliable programming language, where there's lots of type checking. And one of the things that they have is kind of an easy syntax to create the same sort of thing that my library does, where, you know, you say, oh, this special integer type that I just made is between 1 and 20. Now, what Ada doesn't have is the ability to compute new types based on expressions. And it also doesn't have the lack of bounds checking when it's known to be safe.

So if you assign to an integer between 1 and 20, there's always a runtime check in there, and I believe it throws an exception. That's kind of usually the approach that a lot of other languages take. They check all of your operations and throw an exception. Or they have kind of the same concept as the unsigned integers in C++,

where if you go over, they wrap around. Yeah. Okay. So do you then recommend mixing and matching your bounded integers with the standard ones? Or do you recommend like a wholesale switch for, you know, like performance versus flexibility versus safety? Yeah. for performance versus flexibility versus safety? Yeah, so the goal of my library

is to completely replace all uses of built-in integer types in C++. One area where I'm not able to do that at this point is with non-type template parameters. So for instance, if I have a standard array, the template parameters for that are a type and a size. So the size is a size T, and you can't replace that with a bounded integer because it has to be a built-in type

to be a template parameter. So my ultimate view of how I feel the language should be at some point in the future is that all integer types are either the bounded integer or an unbounded integer, like the GNU multi-precision library or the Boost multi-precision integers, depending on what your goals are. Like on the one hand, you have fixed precision at compile time integers. They have no indirection, no memory allocations, and in fact give you better performance than using the built-in integer types. And on the other hand, you have the arbitrary precision integers, which can grow as big as you want and kind of match with most people's expectation of what an integer type does. Okay.

Now, I'm trying to wrap my mind around just using this library. Like, I don't know, say you have a bounded integer type that's a member of a class, and then you're operating on some other bounded integer types. You add them together, it generates a new type, which represents the new extents that are possible. You want to assign it to your bounded integer member variable. I guess what I'm trying to say is it feels like

practically using this library would make extensive use of auto, basically, because you're generating new types all the time. So if you want to assign it to something where you can't use auto, it seems like the library might start getting in your way. So my experience of how I find it most useful to use this library is that your goal should be to specify your types just at certain interface boundaries. The primary one of those would be in, like, for instance, getting user input. If you're reading input from a file or a network or, you know, standard input or something and uh you know you're asking um say you know what uh

i don't know like what's your player's level let's say if you're making a video game and levels can go from one to a hundred you would create a bounded integer that's between one and a hundred and any internal calculations that you use from there um your goal is to not specify the type, because then you can get the type wrong. Like a lot of times we feel that by specifying the types, like if we say like, you know, int x equals, you know, the result of some function call, we're saying this function returns an int, and I'm documenting it there. But really, that's not what you're doing. What you're doing is saying, I'm calling this function, and it's returning some value, and its type is convertible to an int, and I'm converting it to an int.

This is kind of the focus of my other presentation at C++ now this year one of the main, one of the examples that I gave in there was like if you, for instance, were to call a function, trying to remember the example here, it was a spacecraft um where i believe it was the aryan 5 they um had a function it returned a 64-bit floating point value and they stored the result of that into a sign 16-bit integer value causing uh bad things to happen the rocket exploded 35 seconds after launch or so. And looking at the code, everything looks right because you're saying, oh, okay, I'm taking the result of this. It's a 16-bit signed integer, and I'm doing some stuff with it. But it had the same problem that I'm talking about here, where when you specify the types in C++, it doesn't mean what we've always thought that it meant. So yeah, you do end up using auto a lot, and I think that's a good thing,

because it means that your types are exactly what they should be. Like, I don't care what the type is of my intermediate variable, just that it can handle the result of this. So how I often find myself using this is, like, if I do have some sort of class that needs to have a member variable and I don't want it to be a template for whatever reason then you know you can give it the type that you expect the result to be make that the member variable and then when you are doing your

calculations on your variable and you're going to assign it ultimately into that member variable, what you do is that you put in a static assert after you do your calculations that say the type of this calculation is the same as the type in my member variable, and then you do the assignment there. So that way you actually do have the check in there to tell you this is exactly what I expect it to be and it's not something else. Okay. Does that kind of

answer your question or explain kind of how I would use it? Yes. So what's the future of this library? Are you considering proposing bounded integers into the standard? Yeah, I think that is the ultimate goal of it. I would like to have it in. I think it's really helpful for

something as fundamental as integer types to be in, if not the standard, then at least in Boost. That would definitely be the next step for me, would be submitting it into Boost and getting a lot more exposure and a lot more real-world usage out of it.

And then the ultimate goal would be to put it into the standard library. Have you taken any steps to get into Boost yet? So I am still working. There's one more major feature that I want to add in, and it may change the interface. So currently, the integer library only supports the same range as the built-in integer types in C++,

which is only guaranteed to be 64 bits. Right. What I would like to do and what I'm going to be doing in the near future is working on making that be arbitrarily sized. So you can have, say, a 4096-bit integer, which would be really useful in cryptography, for instance, in a way that doesn't require any dynamic allocation

and has code paths that are optimized for integers of that size, because there's different algorithms that you can use for, say, multiplication, there's kind of the traditional, like sort of grade school algorithm, there's, you know, there's lots of there's lots of various algorithms that you can use that are some of them are efficient for very small integers, like 64 bits and 128 bits. Some of them are more efficient when you get up to a few thousand, some in the few millions.

And the bounded integer library is able to see exactly how big the integers are, so it can take advantage of those algorithms without any sort of branches in the code to first check the size and then do the algorithm. So that be my next step and then after i get that in then i would work toward getting it into boost okay i i could see a use case and um i don't know if you already support this to have a bounded integer type that can or a bounded integer type that can hold any bounded integer, if you will, and respect what it was.

So basically, I'm thinking like the analog of std function to a lambda. A lambda is a difficult thing to work with. You don't know exactly what its type is going to be at any given moment. But an std function is something you can pass around. But it's a little bit different. difficult thing to work with. You don't know exactly what its type is going to be at any given moment, but an SC function is something you can pass around, but it's a little bit different. I guess I'm thinking your compile time checking versus something that's purely runtime checking.

Does that exist? Does that make any sense? I think the closest thing to that, right now you can create a bounded integer that has the largest possible range that you can hold in a bounded integer. I don't really feel

like that buys you too much. And then once I expand it, then that also means that the size of the object can get arbitrarily large. And then you kind of have the same thing like, so standard function can hold an arbitrary callable object,

and it does this. It has a lot of optimizations in it, but in the general case, that requires a dynamic allocation, and it always requires a call through a pointer to a function. So I think kind of the analog of that would be something like the GNU multi-precision library or the Boost multi-precision library. Like a big number class would be kind of the analog

once I make it arbitrarily large. And you'd still have those same performance downsides of dynamic allocation and indirect access. Yeah. Yeah, I would have to have some sort of indirect allocation and indirect access. Yeah. Yeah, I would have to have some sort of indirect access regardless, yeah. Do you have any plans at speaking at CppCon this year? On Bounding Injures or any other work?

No, I will not be at CppCon this year, unfortunately. Maybe, hopefully next year. I'd really like to go, but it just didn'tpp con this year unfortunately um maybe hopefully next year i'd i'd really like to go but it just didn't work out this year okay uh before we let you go are there any other projects you've been working on lately that sort of container library, I guess. The ultimate goal here is to write a book on containers in the C++ standard. So like vector, list, deck, array, string, all of those. And focus on common implementation techniques. Like for instance, for standard string,

you have the small string optimization. And for deck, you have variations in what the size is of the internal array, I guess you'd call it. And so I'm kind of working through and trying to create a readable implementation of the standard library and use that as examples within the book. That's kind of the other project that I'm working on right now. Okay. Okay.

So what is the title of the book you're working on um i share that yeah i i don't know that i i necessarily have a title yet okay um that that's always the last thing that i do that's that's the hardest problem in computer science is coming up with a good name for things that's true okay um is there anything else you wanted to share or should we let you go um i think that is everything that i have well i will give a shout out if the talks whenever the talks from cpp now get posted c++ now get posted uh that was a good talk you gave this year on um on free functions it'll make you think it'll definitely make our listeners think if they get the chance to watch it That was a good talk you gave this year on free functions. Thank you. It'll make you think.

It'll definitely make our listeners think if they get the chance to watch it. Thank you for that, and have a great day. Thanks, you too. Where can we find you online, David? Yeah, so you can find me on Stack Overflow. I'm David Stone. Or you can find me on my website website at uh double wise.net uh the word double the word wise.net okay thank you so much for your time have a great day

thanks so much for listening 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 that also you can email all your thoughts to feedback at cppcast.com i'd also appreciate if you can follow cppcast on twitter and like cppcast on facebook and of course you can find all that info and the show notes on the podcast website at cppcast.com