CppCast - Boost::Process

Episode Date: September 29, 2016

Rob and Jason are joined by Klemens Morgenstern to discuss his experimental changes in boost::dll and his proposed boost::process library. Born in 1988 in Dresden, I have a Bachelors in Electrical Engineering and Master's Degree in Microsystems & Microelectronics. Fell in Love with C++ while working with embedded systems. Klemens was working full time as a C++-Developer from 2013 until early 2016, and is now starting his own consulting company, trying to bring C++ to C-Programmers. News Optimization Subtleties Using C++ in Low-Latency Trading Herb Sutter: To store a destructor CppCon 2016 Playlist How to avoid bugs using modern C++ Vcpkg: a tool to acquire and build C++ open source libraries on Windows Why a C++ package manager can't be written in C++ Klemens Morgenstern Klemens Morgenstern's GitHub Morgenstern & Walther Links boost::dll Mangled Import boost::process Sponsor Backtrace

This episode of CppCast is sponsored by Backtrace, the turnkey debugging platform that helps you spend less time debugging and more time building. Get to the root cause quickly with detailed information at your fingertips. Start your free trial at backtrace.io.cppcast. And by Meeting C++, the leading European C++ event for everyone in the programming community. Meeting C++ offers five tracks with seven sessions and two great keynotes. This year, the conference is on the 18th and 19th of November in Berlin. Episode 72 of CppCast with guest Clemens Morgenstern recorded September 28th, 2016. In this episode, we discuss a new package management tool for Microsoft.

Then we talk to Clemens Morgenstern. Clemens talks to us about the Boost DLL and Process Libraries. Welcome to episode 72 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? All right, Rob. Had a long week at CppCon. Yes. I'm still recovering. How about you? Yes, still recovering. I could sleep most of the day today. Yeah, that sounds about right.

I did not get to sleep most of the day today because work. It was actually my daughter's birthday today, so we all woke up a little bit early for that. Oh, that's fun. Yeah, she wanted to open her presents up right away, of course. Yeah. Well, anyway, at the top of every episode, i'd like to read a piece of feedback this week i got a long email from chris and he wrote in about the last episode saying in the last show with chandler caruth someone said something to the effect of why are some people slash companies stuck using pre-c++ 11 compilers why don't they upgrade

and he says an important answer that is rarely discussed is predictability your listeners might be interested to hear that in many domains knowing exactly how the compiler will generate code and how that code will execute on particular hardware is paramount to achieving performance goals for example in finance and console game development you may want to be absolutely sure that code gen changes won't result in unexpectedly slower execution in latency critical portions of your product when it's deployed to your production hardware. Sticking with an older compiler allows you to build institutional knowledge of and confidence of the output of the compiler will generate for a particular input.

You can then build coding standards around that knowledge in order to achieve your performance goals. And he puts in a link with a good talk with examples about this, and I'll put that link in the show notes, and it shows how sometimes the compiler upgrade can have unexpected detrimental effects on end performance i feel like i buy that like 80 percent yeah except for the the stories that i've heard and the things i've seen in my own code where simply enabling c++ 11 enables compiler-generated move operations, which almost always speeds up the code. But it would be very interesting to get someone on here who can talk more about that. Yeah, definitely.

Not that I wanted to discount our awesome feedback that we just got. I wasn't intending to do that. Yeah. Well, we'd love to hear your thoughts about the show as well. You can always reach out to us on Facebook, Twitter, or email us at feedback at cppcast.com. And don't forget to leave us reviews on iTunes. Joining us today is Clemens Morgenstern, born in 1988 in Dresden. He has a bachelor's in electrical engineering and a master's degree in microsystems and microelectronics.

He fell in love with C++ while working with embedded systems. Clemens was working full-time as a C++ developer from 2013 until early 2016, and is now starting his own consulting company trying to bring C++ to C programmers. Clemens, welcome to the show. Hi. So you are about 10 years younger than the average person we've had on lately, so I've got to ask again now, what was your first computer and programming experience? Old 286 computer and basic on DOS.

So GW basic or Q basic? I have no clue. I was 10 at the time. I'm a bit of a basic historian when it comes to PCs. That's why. No, I built some small scripts, and then I got, I think, Turbo Pascal 6.0. And there I coded a lot. It's been two years later, so I'm thinking that.

But, yeah, playing around with Pascal. I'm also curious about your recent career change. Teaching C developers to C++ was a big topic from CppCon this year with Dan Sachs' keynote. So what prompted you to do that? Well, I've seen a lot of C development and it can be done better. And I like embedded systems where you're directly on the hardware. But it's, well, I've seen so many bugs because of not enough type safety and that sort of thing. And so there can be a lot of improve and, well, you get faster code. And actually, in the company I worked before, I got some controller programmers to use C++.

And it improved their code and reduced the time they needed to program it. So what kind of embedded systems are you programming? Were you... Mostly STM32 controllers, which is an ARM family. Which is quite good support, because you have a GCC port for it.

Right. Still, I think the news is 5.3, but yeah. That's pretty recent, yeah, relatively speaking, yeah. Yeah. Okay, well, we have a couple news articles to discuss. Feel free to jump in on any of these, and then we'll start talking about your Boost libraries, okay? Okay.

So this first one is from Herb Sutter, and it's in reference to the talk he gave and specifically the very end of the talk where he showed this new library he's been working on. The article is To Store a Destructor. Jason, I actually missed the very end of this talk. So maybe you could talk about what he's doing here. Well, to be perfectly honest honest i mostly missed the very end of his talk also okay however but what he's actually doing here is is just explaining how you can store a destructor and explicitly call the destructor on an object later if you need to destroy it without freeing its memory necessarily okay have you looked at this library much um i only his discussion of it

that i caught during his keynote on uh on friday i've actually looked into it um and well as far as i understood it you basically have a defined lifetime for the pointers which are stored in a in a heap and and you can destroy it at your own pace, basically. But concerning the article, you just got to know that you can call a destructor explicitly, which is done in some libraries, like BoostVariant would need to do that because you have untyped memory, basically,

and then you can call a destructor there. Right. And also with some of the smart pointer classes in standard C++, you can specify what you want it to do on destruction, and by default it stores, it calls the destructor. Yeah, but that would be done through a delete, basically, because you have the pointer type. I don't, as it always't. I thought sometimes they actually

stored the destructor in the case of if you wanted to avoid the virtual dispatch when you're passing around shared pointers to base classes anyhow. I forget the details. Next thing I wanted to mention

is the CppCon 2016 YouTube playlist. It's getting updated pretty regularly. It already has all of the keynotes and plenary sessions, some of the panels, and now they're already getting into some of the regular talks. They have, it looks like, four of the regular talks that have gone up so far. And do you have any idea what the number of total talks was? Is it like 100, 150 or something?

I have no, I don't know. It was at least six talks, what, four times a day for four full days of conference. So that sounds like at least 100 right there. And that does not include the lightning talks that were recorded. Right. Lightning talks should be going up as well. And I think everything is supposed to be up within a month.

So I'm expecting we'll see this playlist being updated probably on a daily basis. So Clemens, you did not go to the conference, correct? No, sadly, I couldn't. But I listened. Yeah, I was wondering how it is watching the videos online

without having attended the conference. No, it's still awesome, but you wish you could be there and ask your own questions. But yeah, I watched all of the talks that were online yesterday. But today it's basically a double amount of that. So I've seen your talk and Dan Sacks' talks, Bjarne and Herb Sutter,

and the one about Bitcoin by the guy whose name I forgot. Oh, right. Right. So are you planning to go to Meeting C++? Well, when is that and where? It's in December in Berlin. Yeah, actually, I could do that. Is it December?

That one's much closer to you. Yeah. I figured since you are German, I would ask. Yeah. I don't know yet. I would love to, but no. Okay. We should definitely, we talk about the C++ conferences,

but we almost never mention meeting C++. We should do that. Well, we actually, I spoke to Jens about that when we were out at CppCon, and we're going to do a little plug for meeting C++ just like we've been doing for CppCon in the show intro. All right, very good. Yep.

Will you guys be there or probably not no i would love to go for us yeah yeah the main problem for me at the moment is that amount of travel right around the holiday season yeah is difficult but i would like to go somewhere okay next article is another one from the PVS Studio blog. These are always really great articles. And this one is how to avoid bugs using modern C++. And they go through a bunch of examples using open source code that is available online for them to use their static analysis checker on.

And they have a couple good examples here about when modern C++ can save you from a common problem and when you might not want to use a more modern approach. Yeah. Is there any specific ones you wanted to call out, Jason? I just want to comment that the PVS studio is absolutely excellent at catching errors between 64-bit and 32-bit conversions

and this is something that people ask us on this show why would you ever want to use Visual Studio and that's one of the main reasons is Visual Studio is much better at catching these type of size errors than the other compilers are and PVS Studio is that much better again at catching size things yeah that's a good point how about you clemens you have anything you want to call out in this article well i just only looked over it and um well it's interesting but most of the

things i already do so that's good yeah like like the the for loop thing is just yeah once you have the the range for loop yeah yeah and i actually use it more than i would have before because you have the the boost iterator range and just because i like the syntax i often just use an artificial iterator range there to to use the range for loop. Okay. Okay. And this last one is a new tool. The visual C++ team is putting out called VC package, which is a tool to acquire and build C++ open source libraries on

windows. I wasn't really, it's a pretty short article talking about what to do to set it up and some of the libraries that currently have integrated. I guess if you're only building for Windows using Visual Studio, this might be a good option for package management. But if you're concerned for Linux, it's probably better to use something open source

that targets multiple platforms like Conan, I would think. Yeah, it does kind of seem that it wants to be a direct competitor to Conan in some ways. Yeah, but they say the prereqs are Visual Studio 2015 and Windows 7, so I don't think this would get you anywhere if you're concerned with Linux. Well, in the Reddit discussion, they say basically if you're concerned with Linux, right? Well, in the Reddit discussion, they say, basically, if you're on Linux, use apt-get whatever to find the package or to install the package that you want to link to. And then use find package in CMake to find it.

And then keep that same pattern. Use find package in CMake on Windows, and it'll find the thing that vc package installed. But I don't know. I haven't used it. Conan kind of posted an indirect response to this in an article that I think they just posted yesterday.

That was why Python for your package manager. Maybe if we remember, we should link to that in the show notes too just to have a message link to it yeah i'll make a note of that okay uh well clemens let's start talking about a boost process can you give us an overview of that yeah well i mean it's a library to launch other processes and i think it's desperately needed for C++

because, well, there aren't any. We have one in Qt, which then integrates into Qt with IO devices and that sort of thing. I don't know if GTK has something like that. And then you basically don't... I wouldn't know of any which works on several platforms. Yeah, there's one smaller one that for a while didn't have Windows support.

I don't know if it does now. So I guess maybe we should take a quick step back. And you are the maintainer author of Boost Process, correct? Now I am, yes. Now you are. Well, it was started, I think, 2006. Okay. And then it was with a version four it was a review and rejected i think it was five years ago interesting and and then uh boo was sheeling other german guy took it over um wrote 0.5 and that was in a review queue for, I think, two years and didn't change much.

Yeah, I was a bit of an orphan. And then I needed a process library, and so I just took it over and wrote a new library. And then I realized what I wanted to do with it was actually not that hard, so it was a bit of an overkill but yeah so what was the hang up up until this point if you know that prevented it from getting through the boost review process well in 03 it has a lot of macros where you had to write if dev um boost windows api or posix and that sort of thing and that's what you actually don't want if you have a library for that. You want to be able to do the core features without any macros. Then with

the next version, I actually don't know if it would have gone through the review. It just was never reviewed. It just was written as in review. And I think that it had to limit its functionality. So the call things, reading pipes, and that sort of stuff you could do without any macros. But if you wanted to go into asynchronous IO, you had to write them.

And, yeah. But that library was already used. Okay. Yeah. So then I took it over and basically wrote a new interface, which is sort of inspired by Python subprocess and the way Boost Process was before. So you have a variatic interface for a function

if you want to launch a process, and then you can pass your arguments, whatever you want. So you can simply pass strings in to get, well, the args and the command. But you can also put in an environment, which is a class in Boost Process. So you can set the environment variables. You can put in IO, which is done by writing std underscore out or something like that and then greater than and then you write where you want to to put it so it's basically like in a console somewhat and you can put the output into a pipe or a stream or a file

or the null device whatever you like or you can close it. So that's basically the syntax. You either have special types like strings or you have these initializers, and they get then combined. That sounds pretty advanced, I guess, compared to anything I've used. I have used QProcess fairly extensively, but it's the only cross-platform process library I've used in C++. Well, it's actually a challenge because you have so many settings you can pass through the process and you normally don't want

all of them. So if I would open it to all, you can use your 15 parameters, which is a bad design for a function. That's sort of the thing. So what operating systems does Boost Process work on? It sounds like you have good cross-platform support. POSIX and Windows.

I've tried to adhere to the POSIX standard, which we'll see. I've tested it on a Debian virtual machine, and then I tested it on Windows 10, I think I have. Yeah, and there it works. I don't know if it will work on Windows CE, but I don't know who uses that anyway. Because, yeah, it's not current anymore.

Right. Yeah. Okay. I was just curious if Rob has ever programmed a Windows CE. I have not, but I know Rob has done Windows Embedded Development for a while. I have programmed Windows CE. I'm not sure. I'm never trying doing process piping on Windows CE, though.

Okay. It would be fun because I think the API is only available in the Unicode format on Windows CE. So theoretically, I have taken care of that, but I've never tested it. Interesting. That makes the Windows CE API sound better than the Win32 API with its mismatch of Unicode and not Unicode and everything else. Well, if you use the macros, yes, you have to mismatch. Actually, I have a header-only library

which does not include the Windows API. It's because it's in several boost libraries. They have a wrapper around the Win API. We put a lot of forward declarations in. It's very thin. It's actually not even a wrapper. It's just the functions for the declarations of them. And then you can use it without including the Windows API.

But if you include it, it still works because the symbols are defined in the right way. So, and there you have then also functions which overload that because if you have, yeah, if you use create process, it's a macro. It's not a function. But the functions are create process A for ANSI and create process W for WHR.

And so you can overload that and thereby take care of this, which makes it much easier. Yeah, that's kind of brilliant. I never considered defining just the specific Windows functions I need. Then you don't get this mess where some, what is it, when headers define things like min and max that can get in the way of standard min and standard

max. That has always annoyed me. I can look that module up. Though on the other hand, it is limited because you can't forward declare an enumerator. So I needed a function which does that. And yeah.

So what I did is I know how the system DLL is named, so I just import it by get proc address. Okay. Because it's randomly used, so it should work. Should I go over the features I have? Yeah, sure, go ahead. Okay. So what you can do is put in the environment, which you can change on the fly.

So you can basically say, I want my environment plus this value, or I want append this path to the path variable. And you can just put that into the function as an expression. Is the environment just like a string map or something? Yeah. Okay. Just the map button.

Yeah, basically. And yeah, it's something you can do, or you can completely create your own. And then you have um the wait um then you can group processes which because the problem is um i can't send a sick terminate so you can't say yeah exactly sick terminate is when the child can react right sick term okay uh yeah i think and sick kill is the what i use is terminate where it's it's is when the child can react, right? Sick term. Okay. Yeah. I think, and sick kill is the, what I use is terminate,

where it's killed without notice. And the problem is, that doesn't work on Windows. Windows doesn't have such a functionality. Right. Therefore, it's not provided. The problem is, if you launch a child process,

and this starts again another trial process, and you just kill the first one, the other one lives on. What you can do is you create a process group, which is, on POSIX, it's a process group, on Windows, it's a job object. You put several processes in, and if you kill that

one, it kills all you have grouped into this group, and all their children. Sounds horrible. I have actually had to deal with that in cross-platform Windows development where I've had to launch... The solution that I came up with, which is horrible, was to launch a small batch script on Windows that walked the process tree and killed all of the children manually.

Okay. Yeah, it sounds horrible. Yes. But it worked. Sure. A lot of things which work on Windows. Well, actually, if you do that, the child process could still create another group

which would not be part of that. And that depends on which Windows version you use and all that sort of stuff. So it's rather strange. But your library takes care of all that? Nope. That's platform-defined because I can't do that. Okay.

It really depends on how you launch the process. There is no way of accessing that. Because if you group a process, it cannot change its own group because it doesn't have a handle to that. I could hack something together where you walk the process and find the handle, but yeah, not really functional. And what you can also do with the library is asynchronous IO. So you can create a, the library is asynchronous I.O. So you can create

a, it's called an asynchronous pipe because I need to use a named pipe on Windows, but not on POSIX. And you can use it with Boost.aco. Oh, interesting. I love that library. And then it takes care of

all that stuff. You even have a wait for exit function then if you pass an ACO IO service. And if you do that, you can even, if you like, to put the output into a future. And the IO service takes care of that, and you can later on get it. Well, that sounds pretty handy. I hope so. So I'm curious. You said it's a variadic list of things that you can pass to the process when you launch it.

The environment, the standard in and standard out kind of things, if I understood correctly. What happens if you say, like, in your process list, pass two sets of environments, or you redirect standard out twice? Then just the latter one is used. Okay. I think. I don't know if it's possible to put a check in there. Because you can actually split up commands. You can not only write args equals and then set your arguments.

You can actually write args plus equals one set of lists, then you put the next one behind that and add another one. So you can also use the same thing with the environment. You can write several new variables you want in there after another. So, yeah, if you... This is what would happen if you used the IO.

It would use the last one. What you can actually do is write std out and stdr and then pipe it somewhere. Just for fun. Yeah. Are there any other features in Boost Process that you wanted to highlight or that are

unique compared to other process libraries? I might. Nothing. Well, you can use it with coroutines. That's also nice. You have basically three functions to start a process which is a constructor of a child class you can just spawn a child and say i don't care about the handle or you can use system which is basically an overload of std system and if you use that one you boost acu co-routines you can pass the

yield context of the coroutine, so the coroutine stops until the child is finished. Wow. It sounds way better than what I've done with process stuff. It took me a while. It's one of the things which I just wanted to see if it could work, and then it becomes a feature. So what's the feedback you've gotten so far in the Boost review process then?

Well, one idea was to create a, how is it called, domain-specific extension language, an embedded language. But yeah, that's always new. I had a lot of bug reports, which were mostly right. And it seems a lot of people are testing it. And the official review starts end of October. Okay.

So that will be, I think, 10 days. And then we'll see if it gets in or not. But since I announced that, I got a lot of feedback, which is quite useful. And originally, for example, the Unicode version of the Win API, I originally removed that because I thought, who uses that? But actually, a lot of people do because if you have special characters

like our German ones, you actually need it. Yeah. And so now that's what I'm currently working on. That's one of the things that we're lacking. And always a discussion about why can't you have a SIG term? I can't.

Right. I wanted to interrupt this discussion for just a moment to bring you a word from our sponsors. Backtrace is a debugging platform that improves software quality, reliability, and support by bringing deep introspection and automation throughout the software error lifecycle. Spend less time debugging and reduce your mean time to resolution by using the first and only platform to combine symbolic debugging, error aggregation, and state analysis. At the time of error, Backtrace jumps into action, capturing detailed dumps of application and environmental state. Bactres then performs automated analysis on process memory and executable code to classify

errors and highlight important signals such as heap corruption, malware, and much more. This data is aggregated and archived in a centralized object store, providing your team a single system to investigate errors across your environments. Join industry leaders like Fastly, Message Systems, and AppNexus that use Backtrace to modernize their debugging infrastructure. It's free to try, minutes to set up,

fully featured with no commitment necessary. Check them out at backtrace.io slash cppcast. So, so far we've been talking about boost process, but you're also working on something called boost DLL, is that right? Well, collaborating. Okay. Yeah, what I try to do is,

again, just to see if it works, if I could import a manual symbol. So you guys know if you're compiling C, you have the clear name there, but as soon as you get into overloaded, you need to mangle it. That is to put in some mangle name for the types you pass and that sort of thing and i always thought why can't i write a plugin system which could load that i mean so i could overload i could

load overloaded functions from a dl and well i try to do that and it actually works for two compilers or no two abis which two then msvc and the etanium abi which is used by gcc clang i think intel uses another i don't know it was i think there was a third compiler which which used that one and so that that can be used. Other ones could be implemented. I didn't do that yet. It's still experimental. So basically the way it works is you define what you want by passing the types.

Because the problem is the type you see in your code is actually not the one you use. Because if you use std string, it's std string, char, std allocator, and so forth. Right. So if I try to parse it, let's say you want a function which takes a string, and you just give me a string which says std string, I would never find it, because I don't know what it is, and it's not exported as such. So what you do is you say, I want this function, and then pass the signature. Just two things. First of all, that then can actually find the function.

And secondly, you import it sort of type safe. So what you don't have is the return type. MSVC exports return type, so I check that. GCC does not. So you can import a function, an overloaded function with the wrong return type, which can cause very undefined behavior. Right. But other than that, it basically works. So what you can do is import functions. Obviously, you can do is, well, import functions.

Obviously, you can import member functions. You can import constructors and destructors and type info. So basically everything. And the problem is you don't know if you have a class which is hidden in the DLL. It's not defined in your code. You have no way of knowing how large that one is. So that's an information that you've got to have. But then you can say, I want this class,

and I define locally another class, which I say is an alias for that. Okay. And then you can use that instead, and the importer will replace the class name with the one you required. And then you can import a whole class, basically. Say, I want that. It constructs that. You need to know the size, of course. And then you can use it, get the type info, get methods, and use it.

There's some ways of dumping symbol information, at least on Unix, that could give you the size of a struct, I think. Have you considered taking it that far, or am I just wrong? No, you're right. If you make a debug build, you have the size in there. Oh, you need a debug build. Yeah. Or you can provide the information

any other way, but that's basically the point. You would provide the information any other way than in your code. So I don't think there should be a standard for that i mean it could be even easier you can just say i provide a function which tells you the size or not even the function a variable which you can also import so you just define say that's my size you import the symbol then you can allocate the memory okay so you just the one thing that really caught my attention is you said you can get mangled constructors and destructors.

Now constructors, again, unless I'm wrong, are not regular functions. You cannot actually get a pointer to a constructor in regular C++. But yet with your library, you're saying, I can't. It's obviously exported because it has an address. The signature was a thing of trial and error. Okay.

It's basically a C-DECL function because you have the call conventions which you've got to look into. I think that was a I found some work around so it worked. It's actually even more fun because GCC exports two constructors. No, it does not.

The Itanium ABI has two constructors defined, which is one where you have already allocated the memory, and you have another one which allocates the memory. Okay. And I actually tried to use that, but the problem is GCC doesn't import the latter one. So it's actually in code, but it's never used because I don't have a fitting compiler. And I think Clang doesn't either. I don't know if any compiler

does that. Interesting. Same thing for destructors. They have even three destructors. There's one if you're destructing the whole object, then destructing it and deleting it, and then you have one where it's... I think that's the one called if you're in a type hierarchy, and it has children and that sort of thing.

That makes sense. Yeah. What are some of the use cases you see for using this boost tool? I think if you want to write a plugin system, because then you can say, I want this concept of a class imported, say okay, it's named that way, I need those

functions, and then you can see what is implemented and whatnot. What you normally would do today is you have a interface with a lot of virtual functions, and you import it and get back a shared pointer. Which, again, also works. But if you

would have a larger plugin system, you could use the Boost.cll to know exactly what you're importing. But, yeah. I mean, last plugin system I wrote had two functions, so that would have been an overkill. Right. Well, I think

the fact that it's difficult to load modules from across C++ DLL boundaries and forcing you to do extern C or something else has led to this world where we're used to extremely limiting our interface

to one or two functions, like you're saying. So maybe this would open up a world where people would feel like they could make more rich DLLs. You can actually import overloaded functions. So if you want to import a member function, you have to first give the class and then the signature without the class. And then you can write another signature behind that, and another one, and can even change the type. So you could write T and then func, or whatever the name of the signature is.

And then you write after that const T, and next signature, and then you can import a set of member functions, but it's all with the same name but an overloaded one. And that all gets into one object, and you can call that overloaded. That's pretty cool.

It might be useful if you need a copy and a move, for example, then you can just overload it. Right. So what kind of feedback have you gotten on this one so far? How's it looking from the Boost community? I don't think anyone has tried it. Okay. It's just looking from the Boost community? I don't think anyone has tried it. It's just arrived in the experimental. It's now in the release Boost version.

So if you use Boost DLL experimental you'll find the manual import, I think. And smart library. But yeah, it's not stable. I tested it on three compilers I think I tested it also on clang yeah yeah clang GCC MSVC but it's not mature

enough the thing is I remember from five years back but I wanted such a feature and so the thing is that it exists and you can use it uh it's nice but yeah it's not not that stable do you have an idea when it might become more stable experimental phase okay it's it's as simple as that yeah i've i've covered everything i i think i can do with that but then someone got to try. Also, the thing is, you have a storage of the symbols because that's the way it works. It reads out the whole symbol table,

then it mangles it all, or what it can, and stores that. The problem is you can access that, and then you have a pair of strings, mangled and demangled, for each symbol. And you can say, I want that symbol.

I have not yet thought of a way to actually analyze the symbols you have and how that would work. Yeah, I was wondering if there was some world waiting to be opened up to us here where it would be possible to just walk through the symbol table with your library

and dynamically generate a scripting interface for a DLL, for instance. That would be possible if you have every type defined, which is used there, basically. But I have no problem which I need to solve there. So I don't know how that would look. Because you've got to go in some depth. because you can see the string, but yeah. Right. It's almost like you would have to walk it and use that to generate a C++ source file that had the interfaces that you needed in it, but then you still wouldn't know the size of the objects, which is the problem you already mentioned.

Maybe we could do something like that. Importing a DLL at one time into JavaScript. Yes, I'll let this keep you awake tonight while you tell me if that's possible. I know it's a problem because you have to know at compile time what the type is. So that's sort of a problem. So basically what you would need to do

is define every possible overload or signature you want to use, then look which match, but then you still would have a runtime polymorphic interface to call the function. Which would be possible to do in JavaScript, actually.

I'm almost wondering, thinking almost of it like a backward swig. Have you ever used swig? Nope. used swig nope that will take header files and generate a binding layer which then lets you so from your c++ headers then you can use ruby to access your c++ library if instead you could just throw a dll at it use your tool to generate the binding layer and then generate your interface or whatever to link to it. That's an interesting idea. Well, you wouldn't have a return type then.

That's still a problem, at least on GCC. Yeah, okay. Yeah, it does sell there. And that's, well, that's a hazard. That's kind of important. Yeah, I've mismatched return types often enough. That's never a good thing. Right. Right.

Yeah. But again, if somebody tries it out, then I think we can turn it into a feature. Because, yeah, you can actually analyze all the public entry points. That's neat. Huh. Okay. Is there anything else you wanted to mention

about either boost process or boost DLL that we haven't gone over yet I don't know I feel like it but I don't know what exactly well so I see that boost 1.6.2 was just released a few hours ago

so if I download that I will have your Mangold DLL, correct? Yes. But this process is not in there. No, hopefully in the next one. I really

hope it goes to the review. It's about time we got a process library. I would personally like to see one in the standard. I think that's almost as important as file system in some ways. I think that's almost as important as file system in some ways. I actually checked that one, because what I use is, I use Boost Fire System.

I use Boost ACIO, which is sort of similar to the networking TS. Yes. And Boost System Error, which is, no, I don't use that, I use STD System Error. Already replaced that one. And so if all goes well from the dependencies, that would work out. Oh, because you already have all the dependencies you need.

Yes, that would be very nice. But, yeah, it would still need time. First, I've got to get it into boost. And then I'm not sure about the interface. Because it's really a unique problem. You have a lot of properties, but you can't access them after you've constructed

a thing. That's the problem where most of the other libraries sort of fail, because then either you had a long list of things you could set or you had a lot of small function calls to modify stuff and that sort of thing, and that's what I all crammed together in one function.

Right. Okay. Okay, well, where can people find more information about these libraries and about you online? I'd go to GitHub. Okay. And, well, I'm just starting my company, so there's not much to see on the website,

but it exists. You can go there, you find my email, or you find me in the Slack group, which you guys mentioned. Oh, the C++ group. Okay, and what is the link to your company? MW-SC.de okay well it's written on github just just link to that one okay okay well thank you so much for your time today clemens thank you thanks for joining us thanks so much for listening in as we chat about c++ i'd love to hear what you think of

the podcast please let me know if we're discussing the stuff you're interested in. Or if you have a suggestion for a topic, I'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. I'd also appreciate if you like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Leftkiss on Twitter. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode is provided by podcastthemes.com.