CppCast - D

Episode Date: October 27, 2015

Rob and Jason are joined by Andrei Alexandrescu to discuss the D Programming language, C++ interoperability and more. Andrei even announces plans for a new book on the show! Andrei Alexandrescu coined the colloquial term "modern C++" (adapted from his award-winning book Modern C++ Design), used today to describe a collection of important C++ styles and idioms. He is also the coauthor of C++ Coding Standards and the author of The D Programming Language book. With Walter Bright, Andrei co-designed many important features of D and authored a large part of D's standard library. His research on Machine Learning and Natural Language Processing and a five-year tenure as Research Scientist at Facebook complete a broad spectrum of expertise. Andrei holds a PhD in Computer Science from the University of Washington and a BSc in Electrical Engineering from University "Politehnica" Bucharest. He currently works on the D Language Foundation. News C++17 Progress Update Herb Sutter's Fall 2015 Trip Report Rr 4.0 released with reverse execution Andrei Alexandrescu @incomputable Andrei Alexandrescu's Website Andrei Alexandrescu's books on Amazon Links CppCon 2015: Andrei Alexandrescu “Declarative Control Flow" CppCon 2015: Andrei Alexandrescu “std::allocator...” The D Programming Language

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. Episode 32 of CppCast with guest Andre Alexandrescu recorded October 27th, 2015. In this episode, we discuss the news from the latest C++17 standards meeting in Kona. Then we'll interview Andrei Alexandrescu, author of Modern C++ Design. Andre will tell us why he is now focusing his energy on the D programming language, but still loves the C++ developers.

I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? I'm all right, Rob. How are you doing? I'm doing pretty good. I'm excited for this interview. Yeah, hopefully it'll be a good one. At the start of every episode, though, I'd like to read a piece of feedback. And Jason, I think this might be the coolest piece of feedback we've gotten so far. Because this actually comes from C++ itself.

That's impressive. Yeah. So it actually comes from the Facebook page for the ISO C++ Standards Committee. And whoever manages that wrote, one of the surprisingly interesting discoveries of CppCon was CppCast, the first podcast by C++ developers for C++ developers, as they call themselves. As an avid audiobooks fan, I was always regretting they aren't quite suitable mediums for technical books, but I think these guys have figured it all out.

They talked about recent developments in the C++ community and the standardization committee, new technologies in C++ libraries, make announcements for events, basically everything short of reading source code on the air. But most importantly, interview interesting people who shape C++, take them with you on your commute to work. So, yeah. We should try reading source code on the air

and see how that goes we may have at one point or another I don't think it goes too well in general but thank you so much for whoever posted this on the C++ Facebook page I think we have picked up some new listeners

since this was posted so we really appreciate that and we'd love to hear your thoughts about the show as well. 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 also review us on iTunes as well, which brings us even more listeners. So joining us today is Andre Alexandrescu. Andre coined the colloquial term modern C++ adapted from his award-winning book Modern C++ Design, used today to describe a collection of important C++ styles and idioms. He's also the co-author of C++ Coding Standards

and the author of the D Programming Language book. With Walter Bright, Andre co-designed many important features of D and authored a large part of D's standard library. His research on machine learning and natural language processing and a five-year tenure as research scientist at Facebook complete a broad spectrum of expertise. Andre holds a PhD in computer science from the University

of Washington and a BSc in electrical engineering from University Polytechnica in Bucharest. He currently works on the D Language Foundation. Andre, welcome to the show. Thanks. Something that your audience should know is that I wrote that, so it's as flattering as I want it to be.

So don't take it at face value. Take it with a grain of salt. That's normal. I can't say how many times I've recommended the C++ Coding Standards book, though. I've gotten in arguments with people and said, now wait a minute, item I've recommended the C++ coding standards book though I've gotten in arguments with people and said now wait a minute item number 12 in the C++ coding standards says I'm right here so awesome

very cool so we'll get to the interview in a minute but we do have a couple news items we wanted to bring up so Andre feel free to jump in and lend us your opinions on this the first two articles are actually trip reports from the C++ Standards Committee meeting in Kona. The first one is from STL, which he posted on Reddit, and the second one's from Herb Sutter. And it's great to see that they seem to be making

very good progress on C++ 17. Herb wrote a little bit about modules, saying that they have reached a design agreement, which is great. And they are splitting it into both a phase one and phase two. So I'm not sure what phase one of modules means exactly. And they also basically said they're going forward on ranges and parallelism technical specifications,

and the concurrency TS was approved which is great. I think the comments, yes, the comments on Herb's website discuss the difference between phase 1 and phase 2 modules. So phase 1 is what Gabby presented at CppCon and then

phase 2 would be things like exporting of macros I believe. Okay, so phase one is probably going to be pretty, you know, a good amount of the modules work that we're hoping to see. That sounds like it. Okay. How about you, Andre?

Do you have a chance to look at any of these trip reports? Yeah. Well, I'm a bit wondering why they want to go with exporting macros instead of just designing alternatives to them. I understand the compatibility argument, but also modules are going to be mainly for new code, and anyhow, some work is going to be needed to adapt existing C++ code to modularity.

So what I wish I would see would be some parallel development of alternative language features to macros instead of saying, you know, we're going to take that pig and put some more lipstick on it. The whole macros deal is just very unfortunate for for c++ it's been like a huge square square wheel there in the in the in the whole uh tool chain of c++ so i'm a bit bummed that there's no alternative to it but instead it's it's going to continue just being around well you know i feel like personally i use macros less and less as templates become more powerful and more flexible. Yeah, so this is definitely a trend, and it's been for a while,

but there are still places in which you just can't do without macros, and those remain, and the bummer is nobody's working on just rooting them out. Right. We're never going to get rid of anything, but hopefully they could come up with some better alternative yeah um so the next article is uh about this rr 4.0 which was released uh jason did you want to introduce this one yeah so the mozilla team apparently has a uh debugger that you can record and replay and to be a debugging session. And if you haven't ever

seen a demo of that kind of tool, it is mind boggling just how useful it could be. I haven't had the chance to play with the Mozilla version yet, but I am very curious what it's like. So the idea here is that they really record everything that's happening during the application's execution so that you could go back and see exactly what caused a certain bug to happen. Right. So like in your debugger, you could do step forward or you could do step backward and see what did happen instead of moving forward to the next thing. That sounds amazing. Andre, do you have anything to add to this one? Well, I love what I read. So thanks for sending me the link. It's very impressive and it's a good example of good research.

It looks like very rigorously done. It's not a hack. Right. So the whole thing is well studied, well done. And I love this that it's scalable enough that you can run,

you can have a whole session of major products such as Firefox itself. You just run it and then run it back. And that's reasonable to to ask for which is amazing so i'm very impressed by this development you know from what i can see uh in the in the listings here it looks like it's integrated with gdp is that correct that's what it looks like yeah

yeah so that that's fantastic so essentially you can you can use it with uh with uh most any c pluses program yeah and if it can work with a project the size of Firefox, like you said. Yeah, it does seem like it's aimed at support for very large C++ products like Firefox and Chrome and other tools like this, other applications like this. Very cool. So, Andrei, you recently announced that you're moving to full-time de-development. How did that change come about?

That's right. How did that change come about? First of all, like how long do we have for digressions and kind of, I don't know. We've got an hour. You're good. We got time? Okay. So I was born.

All right. So how did that come about um well as you um as you may have heard uh d has been a side project of mine for years by now and um i've been uh i've been kind of witnessing it uh taking shape from uh from a really um kind of insignificant product that nobody heard of to it's it's in top 30 of most you know, these language rankings that they have, so it's there and people know of it and they've heard of it, etc

to which you reached out thank you very much for granting the honor so, it's been my side project for a while and I've been working at Facebook on other projects and I've been doing my doctorate in the meantime before that, and so it's been always some sort of on my radar, but, but not, not the main show. And so, well, you know, I'm 46 and you guys look a lot younger.

Just a few. So, so you don't know what it's like. So, you know, I'm 46 and, you know, I'm just thinking at this age, here's the thing. One year is a more important resource than it was at 26. At 26, I would say, oh, let me spend one more year at Facebook, make some more money, you know, have some more fun with other projects and stuff. But now I'm thinking, you know, I really want to make an impact here. And if I want to make an impact, there's the notion that there's, you know, there's a time box in which you to make an impact, there's the notion that there's a time box in which you

can make that impact. And I wanted to explore this opportunity of taking some risks in the process, but there are risks worth taking. So what kind of impact specifically are you hoping to make with D? Well, there are two things that are of interest to me. One is growing the community, the D community proper. So clearly, I want to make the language, for example, like increase adoption by two orders of magnitude. That would bring it to the level of that C++ and Java and C have. So that's one thing. And I think the language has a lot of things going for it and Java and C have. So that's one thing. And I think the language has a lot of things going for it

and a lot of merit. But of course, there's a lot of non-technical work that needs to be done in addition to the technical work. The other is like influencing other languages, which is where it gets more kind of interesting, sort of indirectly interesting. I think there are a number of ideas in D that are worth looking at from a general perspective of programming languages theory. I think there's a number of innovations that we have in D

that may impact the history of programming languages as a whole, not only the D language itself. Now, you made two talks this year at CppCon. Are you going to continue working with the C++ community, or are you going to be shifting more and more into D? Great question. You know, the more I want to forget C++, the more I know it.

It's completely weird. Well, I still have a I still have a leg in the C++ bayou if you wish because one great thing about C++ which I think those immersed in it

don't realize very well is its community C++ has a great community and somehow for some reason the psyche and the ethos of that community is its community. C++ has a great community and somehow, for some reason, the psyche and the ethos of that community vibes very strongly with me. They're engineers, they're pragmatic, they're essentially, they're not above anything in a way.

So they could do a cast, a macro, we just talked about macros, right? So they're not, you know, using whatever it takes to get the job done is something that uh that is typical to the c plus community and it's something that i think it's very engineer ish if you wish and also one great thing about the c plus community is that it has been immensely accepting of my uh transgressions and my apostasy, my renunciation of C++ status and moving on to D. They've been always very receiving, very warm. Wherever I went, there's a lot of

good reception that I've gotten. And that means a lot. So because of that, essentially, I find it very easy to stay, you know, abreast of C++ developments. Maybe not as much the, you know, the itsy bitsy details like these trip reports that, you know,

for example, I'm looking here over the trip reports and we have things like, that, you know, for example, I'm looking here over the trip reports and we have things like, I don't know, STD RAN replacement revision 3 and 4531. You know what? I don't know about it. So sue me. You know, what can I do? But at the same time, I find myself that I'm comfortable with a bunch of the new tools that are available to C++ 1.x, and I find it easy to use them to good effect. And, you know, I'll probably continue to do so. That said, my main focus is and will continue to be the D language, which I think has a lot more to offer for a guy like me who likes generic programming.

Well, so then maybe this is a good chance for you to tell us, like, what sets D apart? What kind of problems is it solving that C++ doesn't solve? Yeah. Well, you know, in a way, you can do anything in C++ or even in C. But let's say in C++, which has enough high high level language things to put it right there at the top. So you can do pretty much anything in C++. And that for an expert C++ programmer is a very dangerous point of reference. It's a very dangerous attitude because you think you can do anything. And the reality is you can do a lot of things,

but not anything. So, you know, this is sort of the interesting because D for example, has amazingly great solutions for problems that C plus plus the C plus community doesn't understand. It has, okay.

They can't even imagine. They keep on going with their little things and the mediocre achievements in generic programming where in D essentially you can do things that in C++ you don't realize you're missing because it establishes this frame of reference. Here's what I can do and what I can't do, it doesn't exist. So let me give you an example.

Let's see. Well, let's take regular expressions. So we have regular expressions and, you know, there's a number of engines. Of course, some of the best engines are written in C and C++ and they're fast and they're good and they're, you know, there's a lot of things that are going for them. And then Google came with an engine called V8, right? And V8 is for the JavaScript engine.

But of course, it's running C++. But they do something different. They do JIT. So they JIT the regular expression. Okay. Which is kind of, you know, they take the regular expression, they read it during like the JavaScript compilation,

if you wish, interpretation. And then they JIT the thing and they create an automaton that's specialized for that particular regular expression. It's not a general automaton. It's an automaton specialized for a specific regular expression. So I have this interesting JIT thing and, you know, essentially blows everybody out of the water.

So V8 is like the fastest there is, right? Which is awesome. And in D, you have the chance to generate code during compilation so you have sort of you know a very large superset of constexpr in C++1x so constexpr allows you to evaluate things during compilation which is nice it's very interesting and I think few people realize how powerful it could become and so you have yeah but essentially in D you have everything is a constexpr within reasonable limits, like anything. You don't need to put constexpr anywhere.

Just evaluate it in compilation, it works. And in particular, you get to generate strings, like with full string manipulation, and you can actually generate strings that ultimately get compiled back into D statements. So you have the chance during the same session of compilation to read the regular expression, convert it to an automaton specifically optimized

for that particular regular expression and use it in the same program, the same session. I'm not sure how to explain this. There's no like Lex and Yak involved, right? So within the same run, you get to essentially JIT the regular expression and that's exactly what the DStandard library regex does and That takes you to a complete new dimension. It takes you to different It's a it's a different universe that in C++ you don't realize you're missing

Because this was all you can think of is, oh, maybe I can generate some assembler and jit some assembler thing, and, you know, I don't know, things like that. Or, you know, I could do some macros. Or I could use Lex and Yak style and have a two-step kind of compilation to the regular expression, etc. So in D, essentially, you have all this stuff going,

and it's actually faster than V8. So it's faster than the fastest in the world, which is a lot, right? And it's there. And it's a very good example of things that many people of the C++ community don't understand they're missing. So you're saying, essentially, everything is constexpr by default in D, if I understood correctly. That is correct. It does everything at compile time that it possibly can. Yeah, you can actually allocate objects with new, allocate memory, create arrays, call functions, loops, variables, like pretty much anything except, of course, you can't call system functions. Okay.

And you can't do IO. And, of course, because there's system functions and so there are more limitations to to the engine but essentially there's a full-blown interpreter that's built in right into the compiler and there's no need to qualify the functions in any way i think c++ is missing the point there by requiring people to use constexpr because my first advice would be you know what use constexpr because my first advice would be, you know what, use constexpr like everywhere. Like wherever possible, you want to put constexpr in there

because it's a great thing to do and to have. And essentially that's what Scott Myers says too in his book, the latest, you know, Effective Modern C++. So, you know, if I want it everywhere, why do I need to put it anywhere? So it's just the wrong default there. You know, I think c++ compilers are still catching up on that too i forget i think it was on gcc 4.8

i was throwing constexpr around to see what it would gain me and i i learned that i had to actually um i had to actually uh test the performance every time because sometimes adding constexpr actually made my runtime slower and i don't know why interesting yeah and also the compile time is like it can vary a lot because of constexpr and this this whole thing that this duality of the compiler is that freedom to choose uh to do the constexpr in compilation run i think it's just wrong you gotta you gotta to establish clearly, I want this during compilation, I want this during runtime. So the programmer should have exact control over what's happening.

In C++, that's vague and unnecessarily so, I think. Well, so taking your regex example, I imagine if I were to dynamically create a regular expression string and pass it to the regex engine in D, that it would not be able to do that at compile time then now you would have a slower version of it right it would be a completely different uh code path that would uh have a general generic regular expression engine which is decent but not super fast it's as fast as i don't know pcri or whatever right it's as fast as a

regular engine right it's a it as a regular engine, right? It's a good engine. It's not terrible. It's better than a lot of others. But it's not like the best that it could be because it's a generic engine. And that's totally honorable. But as soon as you put a bang in there, there's a special syntax. You put the bang in there and you use a string constant then this whole generation happens and the link

that c++ is missing there is that it can't take it it can't work with strings during compilation properly and number two it cannot take a string and compile it as c++ code and this is what the key piece that's missing the c++ universe so what direction do you see d heading in and what do you think it needs to become more of a mainstream language? Well, there's been growth. It's just not at the rate I want. So I'm looking at things like visits on the site, participation on forums, downloads of the reference compiler, participation of people on GitHub and such.

And there is growth. It's just not explosive. And there is growth, it's just not explosive. And I want to make it explosive. One way by which that can be achieved is by having a strong corporate sponsor. So if a company such as Microsoft, Facebook, Google, even Yahoo, I'm sorry for that. So if a major tech company would understand the potential of D and embrace it,

then that might be a key factor for enhancing D's success. There are languages that succeed without a sponsor for different reasons. You know, generally, let me open up a parenthesis here real quick. People try to ascribe the success or failure of languages by one thing. They say, oh, you've got to have money, or you've got to have advertising, or you've got to have a company, or you've got to have

this feature, or you've got to have this charisma, I don't know, this leader. So, people try to simplify this very complex phenomenon of language dynamics in simple terms. And I think it's impossible. There are so many reasons for which languages succeed or fail.

Think of C++. When C++ was about, there's Ada, right? There's Eiffel. And there's Pascal. I didn't know Eiffel was i was that old yeah it's pretty old so you know and each had a lot of things going for it and they're very obscure and largely on no reason reasons for which those languages essentially got steamrolled by c++ and i can speculate about if you want me to we're still still inside the parentheses, by the way. So I can speculate

things like, for example, Ada. You know, Intel did not compile Ada well. The call stack for Ada was just weird and Intel was not optimized for that. It was great for the C and Pascal call stack. And the Ada call stack was

not optimized. It was not supported well. I can speculate that that was one reason. Also, it's like, you know, Zeta had this reputation of coming from the military. And it's like, it's pretty like the motto of ADA. We're like Pascal, but more boring, right? You don't want to have that moniker going for you, right? So, and then Eiffel was essentially like, its author wanted to make money off of it. And there's like one Eiffel compiler,

it was like super expensive. And C++ was like free. Specification was free. Compiler was free. Everything was free. And, you know, people picked up on that. Again, I speculate. And so on and so forth.

And Pascal didn't have modules or any form of reasonable portable modularity. And, you know, there's a million reasons. So to close the parentheses, I could say that people try to ascribe the success and failure of languages to one reason. And I think there's really a bunch of reasons for a bunch of languages.

And it's a very complex phenomenon. This whole language adoption by people is just amazing. Parenthesis closed. So to answer the question briefly now, I think that's what stands between D and its hoped explosive growth, I think is a strong corporate sponsor. We could really use that. We do have a corporate sponsor, Sociomantic,

which is a large company, very powerful in Germany, which is going to organize the next year's conference in Berlin. But we need some sort of really committed corporate sponsor in the high-tech world to put D on the map solidly where we want it to be. So another question just about interoperability. Can D work with C++? Is it possible to use D with C++ GUI toolkits like Qt, for instance?

Yeah, so this is very interesting because it's one feature of D that just is not publicized enough. So I'm very happy you asked me about this. And for your audience, I can tell that it's your idea. It wasn't mine. I didn't plan that question. I didn't pay you to ask me that question. So

I think it's a very relevant question because essentially it dawned on me while I was working on Facebook which has a huge C++ code base. So we have on Facebook, which has a huge C++ code base. So we have this company, has a big C++ code base. And the question is, how do you use D within that environment, Melio? And it dawned on me that the one way to do it is by just cooperating well, working well with C++.

And in fact, it does have a very good, excellent level of integration with C++, which is still not sufficiently explored and documented. So let me give you sort of an alternative language. Consider Rust, the Rust language, right? Rust has a very awkward interface with C++. It's very difficult. And not to mention that the syntax is completely different.

It's out of this world. It doesn't look like anything like C++, Algo, familiar. It's just out there. And if you want to start with Rust, you've got to commit to Rust entirely. You can't really interoperate with C++ code bases properly. Whereas in D, actually, we're on the way to allow people to use std string in D. Like std colon colon, you know, the C++ std string in D. And I got to kind of emphasize just how huge this is.

Because std string is like a universe. It has all of the crappy functions, right? It has exceptions, throws exceptions that are C++ exceptions, and has methods and has free functions and has just a bunch of stuff going to layout. You name it, it's there. It's C++ complete, right? Yeah. So it has everything that can be in a C++ code base. It's in std string, right?

And you should be, it's not there yet. We didn't do it yet, but we're working on it. You should be able, you will be able to use std string within D without any cost, without any interoperation. There's no conversions andoperation with there's no conversions and stuff like there's no translation going on um with one caveat uh i don't think we it would have inlining so inlining would be a problem right uh you can do inlining on the d side but you would have to write some d code to do the inlining but uh on the c plus side as soon

as you you know you call function, it's a function code, it's not inlined. Because, of course, you can't really inline C++ into D. But I consider that a minor issue. The main thing is that you can have 100% layout compatible and 100% calls

back and forth and exceptions and returns and whatnot from D into C++ and back, which I think is amazing. And it's huge. And sort of the bigger plan going forward is to essentially have STL for D. Like, not write STL, because, you know, you can write different kinds of containers. It's different.

You can approach things differently. But you can actually say, you know what, I'm getting a vector from C++ code. I'm getting a hash map, an unordered map. I use it in D, I give it back to you in C++, and it's just as fine as it was. So this is the plan, to make it as easy as writing a one line of code, import core.stdcpp.unorderedmap and you have the C++ hash map. And that's where I want to get. So what level does that currently,

to bring it back around to Qt or Qt... Oh, sorry, Qt, right. Or just in general, can you just load any C++ library? Yeah, so there exists a Qtd framework. And it's been abandoned. So one recurring problem in the D community is like people work on projects for a while and then they abandon them. Because the community is much smaller.

So in C++ there's less of a problem that way. So there's a QTD library that a fellow named Eldar Insafudinov, probably a Russian guy, He worked on it for a while, and then he just gave up. He didn't work on it anymore. And then it got taken by other people. He did the bulk of the work, but other people worked on it as well after that. And essentially, my understanding, I'm not doing GUI, but my understanding is that today, if you Google for QTD,

you're just going to find it and be able to use it. I think the one problem that is not solved well currently in the DC++ interface is throwing exception from C++ code and catching them in decode. We don't have that down properly. Importably, it works on GDC, on the GCC backend, so it kind of works but it's not sort of in the language. It's not guaranteed. But your goal is that it could work generically with any

library like that. Yeah, totally. Actually, D has the whole C library. It just uses it. It can call A to Y or whatever from D into... There's no extra cost. It just calls the function. Okay.

So that's not a problem. The only thing is when exceptions come into the mix. Now what about the flip side of interoperability? Could C++ call into D in any way? Yeah, because D has... C++ is extern and you put C, right? Or Fortran or whatever. D has extern C++ is extern and you put C, right? Or Fortran or whatever. D has extern C++ and you get to say

extern C++ and you can actually put in a C++ namespace and it gets the mangling right. Oh, wow. Okay. That's recent. It's this year, essentially. As long as you put you define the code in D to say,

I'm going to use C++ calling convention, C++ mangling with namespace and with these names, it's going to work well. So you can call from C++ into D and back. Again, exceptions are the only fly in the ointment that I see now. Okay, so if it's possible to describe this over the air, I don't know. But I'm really curious how your C++ interoperability works. Like,

are you demangling the C++ names? Or what are you having to do? Yeah, so, you know, it's a great question, because it's one of those things, it's unclear, but in hindsight, it's great. And it's like, how come we didn't think of it before kind of thing, right? That I really want to know now. And then you say, oh, it's trivial, of course. Well, here's the thing. For a long time, we thought of the interoperability wrongly. And this is yet another thing of my favorite topic,

which is a whole community can miss the point. So one great part, let me open up parentheses again. One great thing about being part of several programming language communities is that you get to see how a whole community can miss a point. Okay.

This is amazing. I'm not kidding. The D community is missing some points and the C process community is missing some points. The Perl community I've been at the fringe of is missing some points and a whole community can just not get it, which is amazing, right?

So, parentheses closed. So, one thing that we, one point that we've been missing in the D community was that we framed the interoperation with C++ wrongly. We thought, well, essentially we need to add C++ namespaces, C++ rules, C++ overloading rules, C++, like, essentially like all of these lookup things in C++, we got to add them to D the same way. And there's no other way.

And we've been kind of operating from that frame for a while. And it was like a complete mess. There's no progress. And finally, we figured out actually it's not that problem. The right frame is handle it as a mangling and layout problem meaning the name mangling you got to get right and the data layout the the shape of objects in memory you got to get right and that's it you don't need anything else because everything else you do on the d side you do with the d rules on the c plus side you do with the c plus rules and as long as you get the mangling and the layout

you're done it's it's fantastic so um that was sort of the watershed moment for us. It was, oh, actually, it's a mangling problem. So then we added the minimum features to just get the mangling right, the XNC++ thing. And data layout is very easy because it's compatible between DNC++. And then the compiler is just going to generate the appropriate mangling and calls, and you're done. You're home free. It's amazing.

So on each platform that D runs on, you have to have slightly different rules, then, I would take it? Yes. D has an understanding of the name mangling for the C++ compiler, sort of dominate, let's say, default compiler on that platform. Okay. So that's the only thing. So it knows Visual Studio and GCC. Right. Okay.

Right. But it's not big because essentially there's one compiler for each platform, let's face it. They're going to obey the name mangling for that platform and that's it. So there's not many and the decompiler needs a very minimum modicum of

name mangling rules and you're done. Wow. I wanted to interrupt this discussion for just a moment to bring you a word from our sponsor, Chet Brains. ReSharper C++ makes Visual Studio a much better IDE for C++ developers. It provides on-the-fly code analysis, quick fixes, powerful search and navigation, smart code completion, automated refactorings, a wide variety of code generation options, and a host of other features to help increase your everyday productivity. Code refactorings for C++ help change your code safely,

while context actions let you switch between alternative syntax constructs and serve as shortcuts to code generation actions. With ReSharper C++, you can instantly jump at any file, type, or type member in Solution. You can search for usages of any code and get a clear view of all found usages with grouping and preview options. Visit jb.gg slash cppcast dash rcpp to learn more and download your free 30-day evaluation. And use the following coupon code to get a 20% discount for the ReSharper C++ personal license. CppCast JetBrains CppTools So one question I have is you're talking about all these changes that D is making. If someone jumps into the D community and starts working against the D compiler,

do they need to worry about lots of changes completely disrupting the way they work, or is the language more or less stable? Oh, well, this is, you know, I would answer differently depending on the epoch. Maybe two years ago, I would say it's quite unstable. And a year ago, I would say it's quite a bit more stable. And now I'm saying it's very stable.

It's not as stable as C++, obviously, right? So C++ is like rock-solid stable for obvious reasons. In D, we're just getting increasingly conservative to making language additions. And one good reason for not adding a lot to the language is that the language is already very powerful and it can do a lot of things without requiring changes to the language.

So to answer your question, starting now with D, there is some instability, there will be breakages, but let me also say that with GCC, you're going to break code with every minor release, right? So let's face it. And Visual Studio, the same. So there's still breakage with every release, and there's small language changes and additions.

But generally, we're well within an epoch of stability of the D language. Okay. So bringing it back to C++ a bit, do you have maybe a least and most favorite feature you might want to share with us? Least most favorite features. I might be able to make a guess on the least favorite feature based on the beginning of this. The weird thing is, for example, if you Google for,

and I think your audience would like this, Googling for Folly Synchronizedized which i wrote is is a very nice language uh it's a very nice library for doing locking appropriately um so folly synchronized has a macro that i'm very proud of it's it's like immensely it's just a great macro and it uses a number of tricks that again i'm very proud of because I didn't know it's doable so yeah I'm not again just like any C++

engineer I'm not above writing a macro when it comes to it so it's very hard to say this is the least feature most like I'm thinking more in terms of major areas. For example, I'm bummed that safety,

like memory safety is not more paid attention to in C++. I wish there was some, you know, there are people who say, you know what, we want to have more safety in C++ and there's work on that. One other thing is like complexity seems to have gotten out of hand, the language complexity.

So essentially, it's a victim of everything else. C++ seems to be on, it has momentum, and it's doing great, and there's improvements in the language, but essentially, with every step, they're just giving up on complexity. And that's a bit of a bummer. You know, for someone who already is immersed into C++,

every addition makes sense and there's justification for anything that's being done. But for someone new, maybe like it adds to everything else that they need to learn. And that's more difficult. Okay, so let me switch to learn. And that's, um, that's more difficult. Um, okay. So let me switch to like what things that I like.

Well, here's, I'll tell you the number one thing I like about C++, Herb Sutter. Herb, I think he single handedly turned C++ around in the mid 2000s. He just, he's the single most important thing in philosophy right now and i

don't want to offend anyone but i think herb is it because herb is just the the guy with the leadership the charisma the you know the the preacher qualities the fantastic enthusiasm and the productivity and everything who was capable to just turn the language around and make it like like better than ever before so i think the c process community owes a great debt to herb sutter for his his recent work in the 2000s okay so i feel like if i go and look at the c sharp reference today or the Java reference, like those languages are so much bigger than they were when they were first released. Like I,

I was able to sit down and read the Java language reference when it was first released. Now it's big. I was wondering, do you think D will be able to avoid that complexity that C plus plus Java C sharp? Everyone seems to have ended up falling into. No,

I don't think so. And I don't think that we want to. There's only one notable exception. So all languages grow. Okay. And let's say there's two languages that managed to kind of not do so. One is C.

So C over the years has remained relatively small. And it has acquired a number of features over the years has remained relatively small. And, you know, it has acquired a number of features over the years, but it has been relatively small for decades, right? And the second is the Go language. But it seems to me the Go language didn't quite find, didn't cut on the grain as well as C did. I think C just found the perfect way to kind of cut the problem space there.

It's like a portable assembler forever. And it has that going for it. Go is not a portable assembler. It's just a language and, you know, it's a language with no generics. Like everybody's talking about why Go doesn't have generics. And it became, which I think is really damaging for the Go community,

it became the N-word of Go. You can't say generics with Go because everybody's going to be offended in the Go community. Oh, not that again. Oh, give me a break. So the Go community has made it politically incorrect to discuss generics, which I think is just not healthy. The right attitude is to say we have this problem in the language and

people need generics and you can't just talk that away and that's exactly what they're trying to do. They're trying to talk it away. Oh, actually you don't need generics because you can do it with whatever the interface thing and what. It just doesn't work.

And, you know, admission is the first step in eliminating this denial. So, okay. Where was I? So, yeah. So C didn't grow, but I think C is sort of an exceptional case there. Because C is like, is just the perfect little design It's not perfect, but it's a little design. It's a great design And then we have go which is like has it these issues?

And then there's everybody else and all languages are growing like all languages when used are gonna grow and C process is no exception Java is no exception C sharp. c process is no exception java is no exception c sharp is no exception you just add to them and um i think that's fine because a tool set the more you use it the more you want to specialize it for various needs and that's totally fine okay so you've written some very well regarded books on c and D. I was wondering if you might have any plans that you could share about writing more books in the future. Well, that's going to be in Premiere. So I hope it's going to add a lot of new folks to your show. Okay.

So I do have a little announcement there. Oh. I am considering, it's not a dundee yet but i have the title i have a great title and i'm looking for a book for it that is the most important part so i have a great title which actually i um scott myers gifted it to me he gave it to me so i i asked for the title and he gave it to me okay okay it was a transaction no money was involved but essentially it was a lot of karma involved in the whole transaction so i expended a lot of karma on the title so the title is fastware okay and scott wanted to write fastware for a long time and now

he's like you know what i'm gonna take a vacation i going to just not work anymore. And he's taking it easy. And he doesn't want to write Fastware anymore. So I went and said, you know, I think Fastware is a great title. And I want to put a book behind it. And can I have the title? And he said, if it were anyone else, I wouldn't give it. I'm not kidding. But he said, because you're you, I'm going to give it to you.

So I have a great title and I need to get started. So truth be told, during my tenure at Facebook, I have accumulated just a bunch of efficiency things. And it's really funny. I have a full course. I have a day and a half course on efficiency uh that i'm teaching uh i just taught in germany and people love it and the interesting part is that there's very little material available to systems programmers who

want to say how how do i write more efficient code it's just there's no information on it there's you know there's this article here and there, and the rest is folklore. And most of the times, the folklore is just wrong. So people come with the wrong advice. They just don't know what they're talking about. So then it's very difficult to come with an information in book format that's not going to age really terribly over like 5, 10 years. And it's going to give meaningful advice to people

who want to write efficient software in general, not C++ specific, like all this, like, oh, don't create unnecessary copies. Okay, thank you very much. I knew that. I mean, everybody knows that in the community by now, right? But, you know, real advice on how to write efficient code, efficient algorithms, how to take an algorithm from good to great, and how to develop alternative algorithms. Like, I'll just giving an example few people understand that for example randomization is huge randomized algorithms

it's huge it's weird right like this whole thing in quicksort the best way to go about selecting a pivot you select the random element as pivot and a few people know that and there's theory behind it there's theory in this practice and it's huge and it's great. But also like search algorithms that randomize and a lot of like important algorithms include randomization

as an important element because, you know, if it's random, it's very hard to attack, etc. And you don't have edge cases that bad. So this kind of stuff and it's not there nobody knows, I mean not nobody few people know about it, right

not to mention like strength of operations like few people know things like integer division is slower than floating point division that's true, I did not know that I did not know that either which is mind bogboggling.

Maybe it wasn't true five years ago, and maybe it's not going to be true five years from now, but the important thing here is that you need to know the strength of operations if you want to write efficient code, because you want to do what's called strength reduction. You want to replace expensive operations with cheaper operations. And for most people, floating point operations are very expensive operations with cheaper operations. And, you know, for most people, floating-point operations are very expensive,

integer operations are awesome, and actually integer division, like the worst of the pack, is really slow, because it's like, it's search. So there's a long discussion about that, but anyhow. So this kind of stuff, and this is not available in book format. You can't find that. You can find the research paper here available in book format. You can't find that.

You can find the research paper here and there, but you just can't find it in book format. So I'm looking at Fastware. Many people, to continue answering to your question, many people ask me about updating modern C++ design. And the weird thing is I have material for it. But it seems to me the community would be better helped by Fastware than a revision of Mother C++ design. Well, I know I would read Fastware. Yeah, it sounds like a very interesting book. All right, well, I guess I need to rewrite it then.

We'll be happy to review copies of it while you're working on it, if you would like. That'd be awesome. Yeah. Did you think at all about updating C++ coding standards with Herb Sutter? Oh, actually, that's another piece of news,

but that's known already. Bjarne and Herb are working on that now. Oh. And Herb was very nice about it in his Canadian style. He said, Andre, would you want to

kind of allow us to take this effort and stuff? And I said, sure. And right now, sure, you know. And right now, Bjarne and Herb are working on this CPP core guidelines. If you actually Google for this, you're going to get it. So it's on GitHub, and it's public, and it's high visibility, and it has tooling associated with it, and Microsoft is working on that kind of stuff.

And library, there's a GSL, the Guidelines Support Library, right? GSL, it's a bummer because it's also the GNU Scientific Library, but that's an aside. So they could have chosen a better acronym. But essentially, the coding standards continuation for C++1X, I'm generally happy about. There's a strong effort by Bjorn and Herb and others which seems

to me is going well. Jason, do you have anything else you want to ask Andre while we have him? I guess I have one minor burning question about D still. Do you have compile time or runtime reflection in the language? Yes, and that's huge.

I'm sorry I didn't talk about it. I'm happy you asked me because this is going to take another hour to discuss. Well, it's something the C++ Standards Committee is not moving very quickly on. Yeah. So one great thing about these is it's compile time reflection. And the thing is that you've got to realize that once it's a compile time reflection and you know the thing is that you got to realize that once you have good compile time reflection runtime reflection becomes a matter of libraries it's not a matter of language anymore right so you do it any way you want

because you have the compile time reflection you use it and you get whatever runtime reflection you want and uh this has been like a vision thing for like years now. And in D, we've made concrete. So D has like amazing and amazingly good and really like a friendly, a program-friendly compile-time reflection. And that has led to, because I like to give names to things,

it has led to what I call design by introspection, which is essentially like policy-based design taken to the power of N, right? So it addresses limitations of classic generic programming and policy-based design in C++ by saying, you know what, I have a design and it automatically investigates the components you pass to it and is going to make decisions on how to assemble them, depending on the capabilities of the components, because you have introspection during compilation. Right. So my first incarnation of this design by introspection approach has been the design of allocators, which I talked about at CppCon. Right.

But sort of the true incarnation of allocators is in the D language, which is like complete. And it uses introspection everywhere to figure out what allocators do you pass me and how can I assemble them to great effect. So every step in the process, there's some introspection going on. And it's amazing what kind of power you can get there with very little code. Essentially, it's like you assemble atoms into whatever molecules you want. And you create gold, and you create buckyballs.

And you create materials any way you want by arranging atoms and electrons by hand. It's amazing it's the kind of power that's again it's the c-process community doesn't understand that it's missing right so yeah i'm very excited about this stuff and yes there is compile time reflection it's big so i think it's huge and the c-process the c-process community better like if they know what's good for them they they should have it well i feel like I have to go check that out now. Yeah, look for allocators, D-lang allocators,

and you're going to see it's a big design. It's like many, many, many, many great components, and you can assemble them to create any memory allocation policy you can imagine. Wow. Maybe one good last question is, where should people go if they want to get started on D? Well, Dlang.org is the main site,

and off of it you can find forums, which is where people hang out and discuss language. 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. There's the documentation of the language. There's the documentation of standard library.

There's also, you know, from the main site, there's links to things like code.dlang.org which is a repository of libraries and tools for D. There's well there's issues.dlang.org where we get to submit bug reports because we still have a bunch of bugs and so on and so forth so that would be the central hub dlang.org and from it

there's plenty more. Okay and where can people find you online, Andrei? Do you have a blog or Twitter? Well, I'm kind of everywhere, but not super present. My Twitter ID is Incomputable.

I, you know, I have my own site, which is like out of date and from the 90s or whatever. Erdani.org and I think email is like just if anyone wants to write me and I do get a bunch of emails from folks about

a variety of subjects so I'm reachable via emails Facebook of course I have a Facebook account a bunch of followers there so yeah if you have any questions about anything that we discussed and more Of course, I have a Facebook account and a bunch of followers there. So, yeah, if you have any questions about anything that we discussed and more, just reach me at my email address, which is my first name, andrei at erdani.com. Okay. Thank you so much for your time, Andrei.

Thank you, guys. Thanks for the invite. Thank you. Thanks. 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. facebook and of course you can find all that info