CppCast - Biicode and Turbo

Episode Date: April 15, 2015

In this episode Manuel Sanchez joins Rob Irving to talk about biicode, the C++ dependency manager and Manuel's Template Metaprogramming Library Turbo. As a CS undergraduate at the University of Madrid (Spain) and self taught C++ programmer, Manuel Sanchez has been working on personal projects related to Modern C++ during his free time, most of them related to template metaprogramming and his own efforts to give high level features for C++ metaprogramming: The Turbo Metaprogramming Library. Manuel has been working for biicode since September 2014, he assist his fellow biis by dealing with C++ idiosyncrasies while manage very successful posts about template metaprogramming and his work on Turbo. News CLion 1.0 has finally arrived Visual C++ tools for Windows 10 TP Eric Neibler's Ranges proposal Poll: Have you tried biicode? Manuel Sanchez @Manu343726 Blog and Portfolio Links Biicode Biicode goes open source Turbo

Episode number 8 of CppCast with guest Manuel Sanchez recorded April 15th, 2015. In this episode, we talk about C-Line hitting version 1.0 and C++ for Windows 10 apps. Then I'll interview Manuel Sanchez from Bcode, the C++ dependency manager. Manuel and I will talk about Bcode and his template metaprogramming library, Turbo. Welcome to episode 8 of CppCast, the only podcast for C++ developers by C++ developers. I'm your host, Rob Irving, and I want to start off this episode by thanking Vittorio Romeo for joining me on Episode 7. Vittorio and I talked about quick game development using C++ libraries like SFML and STL, which is really informative. It's pretty cool.

You can make a game in about 200 lines of code. So go check out Episode 7 if you haven't already. I also wanted to say that I'm pleased to announce that CppCon is now a community sponsor of CppCast. CppCon is the annual week-long face-to-face gathering for the entire C++ community. Tickets for CppCon 2015 are not up for sale yet, but there is an open call for submissions, so if you've been doing something interesting in C++ that you'd like to share with the community, consider submitting a proposal at cppcon.org before June 19th. Normally, I like to start off the episode with a piece of feedback. I don't have any feedback to share this week, but instead, I just wanted to quickly go meta

for a minute and say that this episode, being episode 8, is actually a really special episode. I did a lot of research into podcasts before starting this show. And one of the things I discovered was that most podcasts don't actually make it to episode 8. A lot of them just do a handful of episodes before they fizzle out. Maybe they don't find an audience or maybe the host just decides he doesn't want to do it anymore. So getting to episode eight is actually a pretty big achievement. Only, I think, 90% of podcasts don't make it to episode eight is what I read. So I want to thank everyone who's been listening to the show for helping me get this far.

I probably would not have made it to episode eight if I didn't have such a strong listener base. So thank you. And please follow the show on Twitter at CppCast. Like it on Facebook at facebook.com slash CppCast. And please review the show on iTunes. The iTunes reviews can really help me get to new listeners. And share the show with your friends and colleagues. If you're enjoying CppCast, then hopefully they will as well.

So there's one more thing I want to talk about before I get to Manuel, and that's that I've been thinking a lot about the podcast, and I am interested in getting a co-host for CppCast. It's for two reasons, really. The first is just that I listen to a lot of podcasts myself, and many of them have multiple hosts, and I prefer that format. I think you get more conversational episodes that way, which is nice. Another part of that is if you have multiple hosts and you have trouble getting a guest one week, then the two

hosts could talk about a topic between themselves, which would be nice. But the other main reason why I want to have a co-host is when I'm talking about C++ and talking with the interview guests, I only have my own background as a frame of reference. And my background is that I'm a mobile C++ developer. So I'm building iPhone, Android, and Windows applications that are primarily written in C++, but I'm mostly working in a Windows environment using Visual Studio as my primary IDE. So I really like to have a co-host who has a different set of experiences than I do. Probably a Linux developer would be nice just to balance my experience with Windows. And I think having a co-host, one who works in Linux and

myself working in Windows, would be a really great balance for the show. So if I just described you, and you'd be interested in becoming the co-host of CppCast, please reach out to me, and we'll discuss it. And you know, maybe next episode or one of the future ones to come will be a co-hosted episode. So, joining me today is Manuel Sanchez. As a CS undergraduate at the University of Madrid and self-taught C++

programmer, Manuel Sanchez has been working on personal projects related to modern C++ during his free time, most of them related to template metaprogramming and his own efforts to give high level features for C++ metaprogramming, Thanks, Rob. successful blog post about template metal programming and his work on Turbo. Manuel, welcome to the show. Oh, thanks, Rob. Great.

So I want to talk about a few news items before we get into the interview. The first one is that CLion has hit 1.0 and has been officially released. Have you taken a look at this, Manuel? Yes. has been officially released. Have you taken a look at this, Manuel? Yes, I have been working with Slion since the very beginning of the AAP program. And I think it's a very interesting proposal for C++ programmers, since at least for the Linux environment, there's no true ADI for C++ and Slion looks like a

very great alternative. It manage modern C++ through auto-completing engine compared to other alternatives like Visual Studio, etc. and other tools like Resurper and I think it's a very great tool for us. Here at vCode we have been working on a plugin, it looks great. It works perfectly with Lion. And that's, for example, what I usually use here at Bcode

for C++. And I think it's great. We needed that. Right. Yeah, I remember reading a while ago about how CLion and B code kind of joined to work on some integration together. So I'm sure that just enhances CLion even more to have your package manager kind of built in. So the next article I want to talk about is from the MSDN Visual C++ blog. If you're not following Microsoft's stuff, they recently released,

they've been releasing Windows 10 technical previews, and they just released the Windows 10 Tools SDK preview. And there's just a nice blog post here from Arman Sharma on the Visual C++ team talking about some of the specific Visual C++ features that are in the new SDK. Whether you follow what Microsoft's doing here or not, I think it's pretty interesting because Microsoft with Windows Phone and Windows Apps

is one of the easiest platforms to create an app in C++. You can do it on Android and iOS, but it's not quite as easy and approachable. So I think it's a pretty interesting article, and you should definitely go check it out. Manuel, did you have a chance to look at this? Do you have any comments on it? Yes. I think the effort Microsoft is doing about what they call a unique operative system for all its platforms, Xbox, Windows, Windows Phone, etc.

I think it's a great idea and specifically in this article they talk about an API, a Contrast HeadMeet API for Universal Windows Apps. I think it's a very interesting API. Let's see, you are programming with exactly the same code, a program, an app for Windows, for Windows 30, for Xbox, you're unable to branch to say, hey, this app is running in a tablet with a touch screen. Yes, there's a call in the data API, you can put a link there, and it just works. If there is no touch screen, you can go to the else, say, do something else. And I think it's a great step forward on the great for that multi-platform programming. Yeah, absolutely. And the example they have here, which is pretty cool, is, and like Manuel said, you'll be kind of creating

one executable that would run on everything from Windows phones and embedded devices to Windows tablets, Windows desktops, and even the Xbox. But obviously, you know, you're gonna have to do some functionality different between each platform. So you can do something like, say, if is type present hardware back button, and hardware back button is something that would only exist on Windows Phone. And then if that is type present check returns true, then you would go and have your code to do

setting up the back button event handler. And you don't need to do an ifdef. You can just do these runtime checks. So it really is just one executable running against all these different platforms. Pretty cool stuff. So the next article I want to talk about was Eric Niebler posted his ranges proposal for going into the next C++ standard, C++ 17.

And it's actually a really long proposal. It's about 170 pages. So I did not read the whole thing, but I think it's interesting. If you're curious to see what the next, what ranges might look like in C++17, definitely go take a look. Manuel, any thoughts on this one? I really love Eric's work.

I have been looking at range, at meta. It's a tiny metaprogramming library. And I think it's great about both two points. We have ranges, we all know that the STL iterator interface, it's great you decouple the interface with the underlying data structure, but you can apply multiple algorithms to a unique data stream, but ranges are exactly for that, and I think it's a great point and a great step forward for C++. At the same time, at least for me, since I usually do metaprogramming, I think having a standard library component which has a little metaprogramming library on itself inside, at least a bit hidden now,

it's great. For any C++ programmer who usually writes libraries, generic libraries, there is a little set of features and tasks you should do in metaprogramming. here, a float instance here, let's go to this implementation. Let's check if that type is an integral type. Let's go back. And type traits help, but we need tools, high-level tools for for many such cases. So I think having a library with those features for the standard, I think it's a great thing. Yeah, absolutely. So moving on, I did a poll this week, and because I knew I was going to have you on manual, I decided to ask the question to the community,

have you tried B code yet? And the options I gave were yes, I'm glad that C++ now has a package manager. No, I'm not using CMake because B code does have some CMake dependencies. No, but I'm interested in learning about it. And I wanted to know Manuel, do you have any guess as to how the voting went? Yeah. B code, it's all about file dependencies. So, what I really like

about B code is that usually C++ programmers write a library and say, hey, no, zero external dependencies. I think. What's wrong about including, let's say, hey, no, zero external dependencies, I think. What's wrong about including, let's say, bust, for example? I think we should have a way to include what we need, not just a bootstrap, a giant library full of headers and related, just

to say there is no trouble understanding the library. I think a dependency manager is exactly what this language needs. So, vCode is our approach for this enormous task. Okay. Just going back to the poll for a second, the votes went that about 30% of the voters were saying that they were using B code as a C++ package manager. About 20% say they're not using CMake, so they're not using B code. And about 40% say that they

have not been using B code yet, but they're definitely interested in learning about it. So I thought that was pretty favorable for B code. So let's start off just kind of rewinding a little bit. For those who haven't been paying attention, what is B code exactly? B code is a dependency manager for C and C++ programmers. What it does is to include what you need from external libraries,

package that libraries in units of code setting, what we call blocks, okay? And in a way, you deploy your library as a block. That block is hosted on our cloud, and then the command line tool we have will search about your includes, match them searching in the cloud and then download what you need. The point is that that works only with including files and vehicles for the first time only download exactly the files you need. Say you have a blog with a library with thousands and thousands of header files and you only include only one, let's say,

full.h. So, vCode only downloads that full. Oh, okay. That's interesting. That's the first point, the bits, that's how I call

vCode developers. That's the first point they have trained to achieve since very huge libraries like Boost or Poco there's no

easy way to let's say just download the entire library that's not feasible okay so I spent some time looking at B code's website last night to, let's say, just unload the entire library. That's not feasible. Right. Okay. Okay, so I spent some time looking at B-Code's website last night. I was looking at your profile, and you just mentioned these blocks, and I see that you have dozens of blocks associated with your profile.

So what is a block exactly, and is it similar to a repository? Okay, a block is a unit of source code sharing. Think of it as a repository. I usually think of blocks and the big code cloud as, for example, even to repositories. You have a software, a library in this case, you wrap it in a package, in a block, and then deploy that package to the cloud, allowing anyone to just include any sources there are in that block, and then the system just unloads the sources they need. The point is that even if vCode is a file-based dependency manager, you're deploying a block since the library needs some kind of semantics, some kind of organization. So if I have a library, Turbo for example, I brought the entire library in a unique block. Usually the usual workflow our users have is to map, let's say, a GitHub repo in a block.

Okay. That's the usual workflow. Then if the library is too huge, they split the library into multiple blocks, organized by features, etc. But in most of the cases, a block maps to a library, to a repository, etc. Okay, so if I already have an

open source library that I've been managing on GitHub and I want it to be to become a B code block, how much effort is involved in that process? That depends on the library, specifically the build system the library depends on. For most of the cases,

we use CMake under the hot boat to handle dependency linking, billing, et cetera. So if the library is Semic ready, there's not much effort on deploying the library to work and to be hosted on B code, just a need in your Semic list file and say, if you are on B big code let's add these flags your usual compile flags to the big code target since because they automatically

creates a series of targets matching your entire sources and their contents. So you don't have, when using V code, you don't have to write manually your targets, your CMYK targets. The tool scans the entire source code and then builds builds a target, okay, with the sources. That sources are usually packaged as a library target. And if you have main files that are, it's one with a main file, say you have tests or examples, et cetera, big code creates an acceptable target for each one. Then

if others use your header, automatically they make links against the V code library target or if you need to build the original block to just run the samples for example you just take the target the main examples target and then it runs so the point is that you usually let's say writing a library from scratch, you usually don't have to do anything. Just because RANS scans your source, identifies main files, builds acceptable targets for those mains, and builds a library target for all your library files, you used to be able to link against any

other block that depends on you. If I'm a user and I want to create an application and I want to get started with B code, what would be the steps that I would take to get running and how long would that take? That's easy.

You only have to go to web page and download the installers we have precompiled installers for most of the platforms Windows, Mac, OS X, Linux Ubuntu etc and just install the client and you're ready you just have then to create a project think of git, git has a git project the command line interface resembles a lot the git interface so you just create a project say by init your project name okay And then inside of it, you can open a blog. Okay. You put the blog name and then it downloads the entire blog and you can play with it. That's what we usually do for

tutorials, examples for people, etc. You use. So the most basic steps you should do to make vCoder run are to download, install the tool, open your common line interface, and then create a project, and then just open the example you want to. There's a lot of examples on our docs, so you're free to choose. Okay, very cool. Another thing I noticed while looking at the B-code website was you have tutorials for creating projects using Raspberry Pi and Arduino. Is B-code pretty popular amongst the embedded community? The embedded community tools we have is not as successful as, let's call it,

standard C++ desktop C++. But the tools works great. You have, we have heard many examples of you write, let's say, an SDL game, 2D game, that your source code is exactly the same for the Windows machine I have in front of me, so the Raspberry Pi or the Arduino or my Linux machine is exactly the same. We have a set of CMake toolchains that you just have to switch between them and the code runs. There is no change, any change in your sources. Okay. Before we move on to another topic,

B-Code made a pretty big announcement today. Do you want to share that announcement with the listeners who may not have heard it already? We have been working in releasing B-Code sources for a long time. We tried it. Here at B-Code, we use a lot of open source programs, source code, et cetera.

And we think the great way to create a tool, to share a tool with the community and encourage people to use it is to be able to see the code when you are using the client in this case. So we were managing to release the code and we today finally we get it and our list the client, the server for example is planning to be released on July or September for too late, but this there is planning to be released in the entire big code, the source code. Okay, so you for example you are now able to run with exactly the same steps as it later. You are able to run

the command line interface just cloning our repo and install the Python dependencies you need and then just run the script and it works. You can see the code, what the code does, et cetera. Send us issues, pull request with the feature you want, et cetera, it's there, it's open source. I think this is a great step forward since having a group of open source programmers helps a lot in this kind of project. There are a lot of people who who said in the past, oh, B code looks great, but

it's not open source. I cannot use something that I have no code. It's there, no? Just check it out. You know that poll that I posted asking people if they've tried B code, I actually saw a couple responses

where people said that they have not tried it because it was not open source. Exactly. So now that's changed, and check it out. It's open source, and I see it's on GitHub. So you think you'll be accepting pull requests if the community wants to help out? Yeah, we have. At this time, there is no pull request, I think.

But there happens to be six hours, no, from the, from the release, but there, there, there's a lot of interest in the, in the community. We have a lot of, you know, that GitHub stars on the repo and there are many of our users that are waiting for to... We were waiting for implementing the B code to touch the B code and send us new features. So moving on, you've written several articles about template metaprogramming and you've created your own library, Turbo.

Can you tell me a bit about the goals of the Turbo library? Yeah, for Turbo, I have started Turbo a couple of years ago, I think, and my goal for... Turbo started as a personal project of okay let's say we

have a cool Turing complete meta programming language it's cool it has a lot of brackets and those stuff but the usual examples are always about the Fibonacci sequence and that's it. Okay, let's program something more interesting. There are a couple of projects there about compile time ray tracer and now a Mandelbrot set, etc. But those usually write things in a very low level programming, meta programming in this case, and they say hey let's write something that gives you high level tools, let's say high level meta functions, list, sequences, etc. For example, I have been working on do like notation like Haskell for

continuation on meta functions, etc. That's the point I had when thinking of Tutor at the beginning, to give high-level features for a true metaprogramming language for C++. Right, yeah, and I've seen a lot of comparisons with Haskell in the documentation of Turbo. Has that been a big influence on you? No. I'm not that kind of guru of Haskell, but I think what is

the thing is that if the meta language is a functional language you cannot mutate a type when it is after its instance, right? So I think there are no sales effects so this is a functional language. So instead of getting the C++ meta language as a scary form of C++, let's take it as Haskell, which is the most very successful language, I think, for functional programming. So what I am trying is that, okay, we need a high-level system, tool, language, whatever you want, for meta programming. So instead of reinventing the whole wheel, let's mimic what it works in this case Haskell. my roadmap with Turbo is to first create a language, a set of language features to really make it Haskell-like. Let's say type classes, algebraic data types, and when that that worked then you should go to the Haskell

prelude and start to write all the preludes. So whenever this works I'm not sure when I will get enough time to do so, you will be able to program in the C++ compiler in exactly the same ways and exactly the same idioms you have with Haskell. Idioms which are currently proud, they work and they are great. Okay. So instead of doing metaprogramming, ignoring that TMP is functional, let's do it fully functional. Okay. Let's say Haskell.

Okay. So if a C++ developer wants to start using template metaprogramming, why would you recommend they use Turbo over another library such as Boost.mpl? Well, as you might know, I developed Turbo in my free time. So I don't encourage people to use Turbo. Now, just because I'm posting changes,

many breaking changes in the Turbo API. Okay, so it's not quite ready yet. So, no, no. But on the other hand, MPL looks a bit ugly for me. Let's say that time name, colon, colon, type, everything in the library. I have an evaluation metafunction that you can put it whatever you want it. Let's say a type trait inside the atap trait, inside the atap trait

recursively, and the thing parses the expression at least for me, than the explicit time name that I type. I think that looks like HTML. So, Boost.npl, I would recommend Eric Nibler's meta. That's my recommendation for now. Sure. So moving on, I see another project on your GitHub is CPP ASCII, which you said is for a course you're teaching at the University of Madrid.

Is that correct? Yes. In my university, there's a group of students, scholars, ACI, okay? And I'm a member of that group. And when there's usually a set of courses about programming, Java, etc., what usually the university manage, but there were no C++. Even the C++ the university teaches is more C, with C out, okay? So I said okay let's take time to teach people C++. I managed that course for three years I think and some people get it. The people who is in the course, at the end of the course, June,

they really get C++. They get RAII, they get no new, no naked new, no naked delete, no, okay? They really get modern C++ and like it.

They usually say, Hey, Manu, why are the universities teaching me Java instead of C++11? Right, right. That's a good question. But they really get C++ at the end of the course. That's awesome. So before I let you go, could you tell me a little bit about,

you know, just what excites you about C++ these days? Are you looking forward to C++ 17 a lot? Or what about the community? That's a hard question. There are a lot of things in C++, in Next C++. There are concepts and I think we need that. Even Java has that kind of checking on its generics and there are ranges for nibbler and core routines and there are a lot of... maybe since I am usually doing functional programming, at least functional meta programming, I

think that monadic future there is flying around around it's a it's a cool feature and instead of getting a wait only for features only let's use it for for for any monetic stuff you can you can write there okay so I think it's a since there's a since it's a new keyword for the language, let's use that keyword for everything you can put there. Not only a unique feature for, in this case, features. So I think it's a great opportunity, await QWR, not just only features. Thank you so much for coming on the show, Manuel. Thank you.

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. Theme music for this episode is provided by podcastthemes.com.