CppCast - Real World Template Metaprogamming

Episode Date: August 26, 2015

Rob and Jason are joined by Edouard Alligand to discuss the use of C++ template metaprogramming in real world projects. Edouard is an experienced kernel programmer, but has spent the last several years working on the hot topic of next-generation databases at software publisher quasardb. He has a strong background in low level programming, beginning with his first programming language: Z80 assembly. Edouard is a C++ enthusiast with a strong taste for template metaprogramming, generic programming, and you're not doing it right if the compiler doesn't crash programming. News C++ Hints C++ Abstraction Penalty: Idiomatic vs Raw How rvalue/lvalue/xvalue got their names Edouard Alligand @edouarda14 Edouard Alligand's GitHub Links CppCon 2015 - How I stopped worrying and love metaprogramming CppCon 2014 - Edouard Alligand Multiplatform C++ Brigand Library QuasarDB Blog QuasarDB Website

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 24 of CppC and tips on the web. Then we'll interview Edouard Allegan from QuasarDB. Edouard will talk to us about template metaprogramming in real-world projects.

Welcome to episode 24 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 all right, Rob. How about you? Doing good. Not much new news for me this week. I did find out I'm unfortunately not going to make it to CppCon this year. So I'll have to go alone to represent CPPCast.

See how many t-shirts I can take with me? Yeah, we are planning on printing up some t-shirts. We'll have to get those ordered soon so you can have them ready to go in September. I tweeted out a picture of our design so it should look something like that.

Yeah, a lot of people seem to be happy with that one yeah i think it looks pretty nice yeah um i'm not sure how many we're going to print but it probably won't be too many so if you are interested in one uh you definitely have to reach out to jason quickly um yeah so at the top of every episode, I like to read a piece of feedback. And this week I have a tweet from Stuart Dootson. And he tweeted us that he was listening to CppCast while dog walking, but apparently his dog was suggesting F-sharp or Swift over C++. I'm not sure if I would take a dog's opinion with programming languages. But thanks for listening.

And walking your dog while listening to the show sounds like a pretty good idea. Jason, do you have something to add? No, I'm just wondering how the dog communicated his preference of languages, that's all. That's a good question. I don't know either. We'd love to hear your thoughts about the show, though, so 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, or you can always review us on iTunes.

So, joining us today is Edouard Allegan. Edouard is an experienced kernel programmer. He's spent the last several years working on the hot topic of next-generation databases at software publisher QuasarDB. He has a strong background in low-level programming, beginning with his first programming language, Z80 Assembly. Edouard is a C++ enthusiast with a strong taste for template metaprogramming, generic programming, and you're not doing it right if the compiler doesn't crash programming. Edouard, welcome to the show. Hi, thank you very much.

Okay, so what system were you doing the Z80 assembly programming on? It was a European computer called the Amstrad CPC 6128. Okay, I've heard of the Amstrad, for sure. I was 12 years old, I think, something like that. Oh, wow. So you got started pretty early. Yeah. Very nice.

Impressive. And you had actually two programming languages that were coming with the computer. You had BASIC, you know, the version of BASIC where you have to put a number in prefix of the line to say where you want to go in the program, which is like, it doesn't make any sense now and if you wanted to do some exotic stuff you had to write some lines of assembly but fortunately when you're very young young your brain is very elastic and it as absorbs a large amount of information very quickly. Not sure I could do it right now. I got started on a Commodore 64,

but I think Rob is too young for either of those things. Yeah. Did not have any exposure with either of those. Okay, so a couple news items to go over. The first one is this fairly new website. I think I first saw about it a week ago. It's called cpphints.com, and it's actually a mailing list that you can subscribe to in order to get daily C++ hints, which is a pretty cool idea. It was put together from the PVS Studio team, and I guess they work on a C++ analyzer,

and they went through 200 different open-source C++ projects and found some of the most common mistakes and are posting their solutions and suggestions to avoid these common mistakes. So that's pretty cool. Jason, do you have any thoughts on this one?

No, I haven't looked at it a whole lot, but I think I probably signed up for the mailing list just out of curiosity. Yeah, I signed up for it two days ago, and I think yesterday I got the suggestion was about reducing the number of if-defs in your code, which is definitely a pretty ugly problem to have. And what was today's? You can actually go to the website and see what all the suggestions are that they've posted

so far. So today's was about using the slash zero literal for the terminal null character. And they go into detail about what open source project they found this problem is and how to go about fixing it, which is pretty cool.

Pretty interesting, yeah. Did you want to introduce this next one? The C++ abstraction penalty? It's a relatively new project here that someone has posted on GitHub where he's trying to determine raw code versus idiomatic C++ code and how much of a penalty we pay for using common C++ abstractions. And it's got some interesting examples that he had

where actually the more idiomatic C++ is actually faster than what you would think of as the raw code. But also just the Reddit conversation about this topic is pretty interesting, because lots of people bring up where other developers have tried to do similarly. I think Alexandrescu or someone has had a project also related to this.

The one thing I thought was pretty interesting about this is it varies by compiler. In the benchmark that he posted, he posted samples using Clang and GCC, I think. And with Clang, the ranges implementation was much faster, but with GCC, it was significantly, significantly slower. So I'm not sure why there would be such a difference between the different compilers, but it's interesting to look at.

Yep. Okay. And then the next article is how rvalue, l L-value, and X-value got their names. And this is actually an article from Bjarn talking about some C++ history and where these names come from and their meaning, which is a pretty interesting read. Edouard, did you have a chance to look at this article? No, actually I had the chance to look at the other two aforementioned links,

but I didn't read that because I'll be very honest with you, I'm not sure it would change my C++. It's interesting, but I try to be very, very focused and very pragmatic about what information I try to assimilate because I get less and less time to read. Interesting. And I'm not surprised, actually, you mentioned that idiomatic C++ is faster than raw code. That's because the compiler is more clever than you. And the raw code is most likely not as good.

And remember that if you're using the STL, if you're using the algorithms and you're using everything it's supposed to be used like that the compiler has been optimized to this it recognizes what you're trying to do and might trigger better optimization techniques

and something which I remember especially when I lived the transition from hand optimizer assembly to trust the compiler and in the Intel optimization reference

book they wrote that don't try to be clever about how you should write loops just write it in a way which is very easy for the compiler to understand and you will get the best performance. Don't try to register, don't try to be clever, just write the loop in the most clear and obvious way and the compiler will do the rest. So I guess idiomatic C++, as you would naively

well not naively but as it's recommended to use library usages gives better performances would be for the same reasons makes sense well let's start talking about your talk for CppCon this year Edouard

it sounds like you're going to be focusing on some real-world examples of template metaprogramming. Could you tell us a bit about it? Yes, of course. Actually, earlier this year I gave a quick talk. We have a C++ user group in France, in Paris, which has an irregular schedule, like it ought to be in France,

but we meet several times a year. And I did a talk with that kind of name which was 20 minutes long, and I said I wanted to talk about metaprogramming is not just something you read in the books and which is a way of saying, hey, look at me, I can do clever things in C++. It's actually very useful um i think it helped us a lot in our project to i mean

the best time to catch a bug is when you compile right it's uh if whatever you can make the compiler do to help you find bugs, you should do it. And template metaprogramming helps in that way. Also, I will talk about very, very basic examples. And I just want people to get out of the talk with their mindset. Hmm, I will try something. It looks interesting. And not necessarily the craziest metaprogram

you might want to write, like let's write a compiler in metaprogram. But just basic stuff, and then you start to realize that it's actually useful and it's really not that hard, especially since C++11. And I will base most of the example on the C++ metaprogramming library

I'm writing with Joël Falcoux, which is on GitHub and available with the Boost license. So what's that library? It's named Brigand. Oh, okay. And, well, just GitHub for it, use it, and it's very complete. oh okay and well just give up use it and it's very complete we have

most of the features you would want to get from Boost.mpl the goal is to have something with instant compile time metaprogramming with instant compile time which is possible in C++ 11. One of the big...

I think it's a valid concern to say yes, BoostMPL, which is Boost Metaprogramming Library, which is most likely the most famous metaprogramming library toolkit. People are going to say yes, it's interesting, yes, you can

do list of types, you can do a lot of things at compile time okay but now my compile time is tenfold bigger ten times bigger than it was before it has an impact in terms of development time in terms of in terms of maintenance because compiling a program in a way costs money if you think in terms of maintenance because compiling a program in a way costs money if you think in terms of a software company because you need to have your compilation grid, you need to have the maintenance of the build, you have developers waiting for the compilation to finish.

And in C++ 11, it's possible to do instant compile time metaprogramming. And if you don't believe me, just download Brigand, compile all the tests we have. We maybe are the only library where if it compiles, it means the tests pass. And it's instant. And we also support Windows Visual Studio 2013.

That's pretty good that you got 2013 support in there. Yes, yes. We wanted to, for the simple reason that QuasarDB is still using Visual Studio 2013 for Windows support. We haven't switched to 2015 yet. So I'm, as someone who's a library maintainer myself, compile time is something that I actually pretty often run up against.

So can you give us any, maybe any clues or hints for what kind of techniques or things to look for to speed up a compilation of template metaprogramming? I'd be very happy to. And the best trick I like to give is the less obvious one. And easiest to understand is to reduce the size of symbols. In Brigand, we don't really have this problem, but you have it with Stempiel because it's

actually a lot of macros with a lot of parameters. And you end up with very large symbols names you could say but what it has to do with compilation time and then i will just point out that the linker has to write simple information information somewhere and you can have very very large gigabytes of debug information being written as you compile if by simply making sure that if you use for example the C++11 facilities of variadic templates you're just going to have less things to write to disk. So that's the first trick. You can also another way to do it is just to do a couple of usings to at some point to

have smaller symbols and then you're going to have smaller symbol files. This trick has been given to me. I will credit the person who gave it to me, Joel de Guzman, the author of Boost Spirit. It's a very surprising trick, but it works. I mean, we gain the time you know in our software and the other way is when doing metaprogramming is when you fully switch to c++ 11 when you actually make the compiler work and not the preprocessor because the usual way of i mean the c++03 metaprogramming library what do they do?

They use the preprocessor, they abuse it to generate a lot of C++ and then they're going to feed the compilers with hundreds of megabytes of on-the-fly generated C++ which is very slow. If you do a proper let's's say just the most basic thing you can do, which is a list of types. In C++ 11, it's just a variadic type with whatever name you want, like list.

And you just do that and it's finished. And the compiler, if you make an instance with three types, the compiler will say, okay, it's three types, and it's the compiler, then if you make an instance with three types, the compiler will say, oh, okay, it's three types, and it's the compiler working. So I'm surprised that using slows it, excuse me, speeds things up and actually reduces the size of symbols,

because without having tried that myself or ever, I certainly didn't think about it myself. I would have assumed that the compiler would have just replaced it with the full length of the name space or symbol name at compile time. I didn't realize it would actually use the smaller name further down. One hint to have this,

if you debug your program at some point with the, let's say for example, Visual Studio, if you have renamed either using or typedef your symbol, it's going to say, oh, this type is short type and not my very long type, which was before I used using. Interesting.

I will definitely have to look into that. Yeah, that's a really great tip. So the project you're working on, is this a Quasar DB? It's a database? Yes. Does this type of project lend itself more to template metaprogramming? Yes, in the terms of we are ready to spend a lot of money on quality. And it's more important to have real quality than to have a fast development time actually

in our case metaprogramming now makes us work faster but when we started the project in 2009 which was actually was only me behind a keyboard writing the first line i knew i wanted static assets i knew i wanted to have modern metaprogramming approach because I was the one guy just starting to write a database, and I wanted to make sure that I could get as much as reliability and checks at compile time I could. And I also wanted to write as little code as I could. With metaprogramming, you write programs, you generate programs,

so that helps you to go faster and it's more reliable. An example for you, let's say you want to, I don't know, at some point, let's say you need to put the value factorial 5 as a constant somewhere in your program, which is, if I'm correct, 720. And if, no, wait, I don't know how, let me compute that. It's 120, not 720. You could just say, hey, for my program at some point, I need to have factorial five, which is 120. And you change your mind later, or you need to change something, and it's supposed to be factorial 5, which is 120. And you change your mind later, or you need to change something, and it's supposed to be factorial of 7.

And factorial of, you can then rewrite the value, update the constant. But if you have a meta program which generates a constant for you, you reduce the probability of writing error. And all of the little things, they add up. Like all these static asserts, especially static

assets I abused them a lot to check the size and the sign of integers at every time in the program I mean this is one of the most maybe one of number one reason to get a bug in a program is wrong sign wrong integer size and with static assets everywhere in your program you can prevent that from happening. Also I think it's also a question of taste because I like it and also I think it's when What it added to the program is to use more original techniques. Like we use a lot of variants and we have a very, very fast serialization library, which actually just you describe the structures as plain C++ structs. And then we have a meta program, which

is going to analyze the structure. And if it can determine how much memory you need to allocate at compile time, then it's only going to use static allocated buffers. And all that kind of thing is added together, you get a lot of performance. Because everything you can detect and find at compile time is something you're not doing at runtime,

which means you're just faster than the other engines. So do you find when you're bringing up new coworkers on your team that they have a hard time working with heavily templated code? Well, we have a 50% suicide rate, it's the cost of doing business, you know. Actually, I think it's a good

filter. First of all, not all the team is working on the core of the engine i mean we have people to go to the customer and write the java code they need to make the software work because they're working in java and they want to plug their trading system uh to quasi db i mean most of our customers are in finance industry which is a lot of java and they just want to dump the market data into a big quasi db cluster and of course we need someone with which is a lot of Java, and they just want to dump the market data into a big CrasoDB cluster. And, of course, we need someone which is a good Java developer to do that kind of thing.

But the core team, it's a way of setting the job, saying, hey, do you want to do some hardcore C++? Come work for us. Right. So you have the core of it is all heavily templated stuff. And then you've got a forward-facing API that's maybe a little bit higher level and more accessible from Java. Yes, we have actually a C API. Okay. Which is a good common denominator and makes sure that we don't have surprises with exceptions. Right.

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, OSX, 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 code base. 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 are developing an open source project, use CLion for free, courtesy of JetBrains. Last year at CppCon, you did talk on multi-platform C++.

Was that based on the same product that you're working on? Yes, because I've been working on this since 2008-2009 actually it's interesting because when you want to do metaprogramming and you have to support many platforms then you learn to how to say it

to learn the differences of certain compilers who have been made in Seattle actually I'm just being for no reason of certain compilers who have been made in Seattle. Actually, I'm just being mean for no reason. When I started the project, I was using the experimental branch of GCC, so I had my fair number of compiler crashes. If you want to support three platforms,

yes, it's harder. And that's why we have this Brigon library which tries to solve part of this problem. But you have to kind of surprise for some reason when compiler doesn't like you using, which is perfectly legal C++. And for some of the time, you want to try to do something very complex and it just crashes.

By the way, if i can give another tip to people doing a lot of intensive c++ especially on windows make sure that you use the 64-bit compilers because what happens most of the time is just your compiler is running out of memory it's not a bug of the compiler is the instance sending a lot of structures and it's using more than 4 gigabytes of memory. So you should switch your Visual Studio toolchain to 64-bit, then you have no issue at all. Interesting.

That's a good tip. We learned that the hard way. Because in our case, not supporting Windows is not possible. So you have two radical ideas. You want to do XfamC++ and you want to support Visual Studio, and you have to make the two of them work.

But we managed to do it. So there's this one warning that I hit personally in Visual Studio. Then if you Google it, I don't see any workaround for it, where it'll complain that the length of your symbols exceeds the maximum size. Have you seen that one? Yes, which brings me to the using magic. So does the using magic actually take care of that? That's what I was wondering.

We don't have this problem anymore, but I think, yes, a couple of using and type devs should solve it. Interesting. Another problem you can have with Windows is also the size of the path if you have too many subdirectories. Yes, right. Although I believe that one's solvable if you use the Unicode path operations

instead of the ANSI ones. Yeah, most likely you're right. But for the symbol one, is it still existing in 2030? In 2013, yes.

I've had to disable the warning in my personal project. I have not checked 2015. Oh, yes. Oh, yes. Okay, this warning, you yes. Yes. Okay. This warning, you just have to disable it.

And what's going to happen is you're just going to, well, you might have incomplete information when you debug the program, but really, we never had any issue.

Right. Okay. That's because we don't need to debug our program because with template metaprogramming we have no bugs that should have been the topic of your talk there should have been if it compiles then it runs yes it's uh yeah it's it's true uh but yeah, that's actually the idea when I want to use a lot of template metaprogramming. And it's interesting that you talk about the team because, of course, from time to time, we have someone in the team saying,

hey, do we really need to be that extreme? Can't we do just something more simple? Are we not just trying to have fun here? Maybe is it really bringing value and sometimes maybe that person is is right it's it's possible i mean you would have to write two exact program one with and one without to be sure but um i think it's really as a whole added a lot of value and verification and my idea was it would be perfect because if i could just by compiling the program know that my program is correct which is a little bit

where we should be headed at with uh let's in 10 or 20 years uh that would be awesome and we are very far from it of course but the truth is when we are refactoring and when you compile and it compiles successfully, you're not that far from being successful. It's a lot of safeguards. I definitely feel like C++ gives us that advantage more than any other language I have worked with, compiled or otherwise.

I agree. I agree. I think it's one of the great strengths and it's going to be even better with concepts. Right. Have you been working with the concepts experimental branch of GCC? Not yet, because, I mean, it's really for a question of time. I think we will wait for something which is a little bit more production ready but we're definitely going to use it intensely when it's going to be available

provided that it's going to be ISV still of course to wait that all of the compilers are going to use it unless we want to fill a code with dev if devs yeah I've kind of been assuming it'll be

about 2018 before we can use it in real code. Optimistic estimation. Well, it looks like you've done several other talks at conferences. Are there any others that you think listeners

should go check out? Not all my talks are interesting. Actually, most of them are boring. The scaling with C++11 talk I gave a couple of years ago gives, I mean, it's a bit too dense. If I look at it right now, I'm a bit not very happy with it because I try to say too many things in a very short time.

But maybe it can give you a couple of ideas about interesting multithreading techniques. And the multiplatform talk is interesting if you want to maybe just as a takeaway have a couple of tips and say, hmm, that looks good. I should maybe, yeah. And I hope my best talk

is going to be the one I'm going to give. Which, according to the schedule

right now, for our listeners' sake, it looks like it's Tuesday of the conference

at 3.15? Yes. Okay. Yes, it's, yes, I think you're

correct. And I'm going also to give an equivalent talk at Meeting C++ in Germany, but it's going to be in English as well. When is that? Is that October? It's December, December. December, sorry. Berlin.

Okay. So is Meeting C++ all held in English, even though it's in Berlin? No, no, you have German talks. But, I mean, if you live in Europe, really, and you like C++, I really think you should go to Meeting C++. It has great value. A lot of talks. It's in Berlin, which means in Europe it's very accessible.

You don't have to cross the Atlantic which I mean for you it may be what's the problem with the US it's convenient right you just have to cross 7000 km especially in Seattle if you live in Europe it's like

jet lag plus 10,000 km you really have to like C++ and so it's like, whoa, jet lag plus 10,000 kilometers. You really have to like C++. And so it's very convenient. I know I'm going to send a lot of engineers of my company there. It's a very good conference. It's very technical, very focused, only two days,

which is a good format. And yeah, definitely recommend going there. Is it comparable in size to CppCon? Oh, no, no, no. Manitalks? CppCon, it's like a... It's big.

It's very big. I mean, it's very ambitious, CppCon. It's very American, since we're doing it that big. And I mean, CppCon is very... I I mean last year was the first edition it's very impressive what John was able to do for the first edition it's a very big conference I mean it's very likely

you're going to have talks that you are in an area that interests you very much so yeah very good very good conference that interests you very much. So, yeah. Very good. Very good concerns.

So is there any other previews or I guess that's the word I'm looking for? More tips you would like to share? Yeah, or anything else you want to entice our listeners to come to your talk with? Well, I will welcome anyone to try the library we're building with Joel Falcoux. We really try to build the equivalent of MPL

for C++11. It's boost licensed, so it's very use it as you want library. Pull request, comment, flame, whatever, just come. You can also feel free to check out our website about what we're trying to do with template metaprogramming and software for queso db very happy if you work in a

very high performance environment you need real speed maybe you should check out self and regarding the conference yeah just just make sure that you have a good night's sleep before. Okay. Well, where can people find you online, Edouard, if they want to find more about you or read some more of your stuff? We have the blog of the company where I blog very regularly, meaning that one time per year,

about C++. But I have a couple of posts and also from people of my team with C++ very technical stuff oriented like how did we do this in C++ in our case I have a Twitter account where I never tweet but of course

you can find me on GitHub to see everything I can do and I'd be very happy to see what you think of it okay well we'll get all those show links from you and put them in the show notes for this week okay to see everything I can do and I'd be very happy to see what you think of it. Okay. Well, we'll get all those show links from you and put them in the show notes for this week. Okay. Okay. Well, thank you so much for your time, Edouard. Thank you very much for the

interview. Yes, thank you for coming. 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 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. Theme music for this episode is provided by podcastthemes.com.