CppCast - DebugView++

Episode Date: September 8, 2017

Rob and Jason are joined by Jan Wilmans to talk about the DebugView++ debug and logging tool and some of his other open source projects. Jan is a Software Engineer at Promexx, contracted by ThermoFisher Scientific to work on integration of motion controllers in Transmission Electron Microscopes. He has been programming for 25 years, started with basic, z80 assembly and later C++. He is now a C++ enthusiast, an open source developer and likes to keep up to date on new c++ developments. In his free time he enjoys playing video games and watching science fiction together with his wife Babette. News CppCon Call for Volunteers Live++ C++ Live Coding Build your first C++ app Why undefined behavior may call a never-called function Jan Wilmans @janwilmans Jan Wilmans' GitHub Links DebugView++ LibIdentify OpenCanary Executors Proposal Sponsors Backtrace JetBrains Hosts @robwirving @lefticus

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 JetBrains, maker of intelligent development tools to simplify your challenging tasks and automate the routine ones. JetBrains is offering a 25% discount for an individual license on the C++ tool of your choice, CLion, ReSharper, C++, or AppCode. Use the coupon code JetBrains for CppCast during checkout at JetBrains.com. Episode 117 of CppCast with guest Jan Wilmans, recorded September 6, 2017.

In this episode, we talked about live coding and undefined behavior. Then we talked to Jan Vellemans. Jan talks to us about the open source for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you feeling today? Doing all right, Rob. How are you doing? I'm doing okay. No real news for me to share. Well, the top of every episode, I'd like to read a piece of feedback. This week, we got an email from Vishwas saying, hey, Rob and Jason, I am not a C++ programmer. I'm a Java programmer, but still like your podcast. Can you guys do an episode for Java or C Sharp programmers

who want to learn modern C++? I always found it really interesting that we have, you know, programmers who aren't actively using C++ listening to the show, Jason. Yeah, and I don't know what to say either. either like we need a good guest who would be able to talk about that kind of thing yeah i mean i've seen you know non c++ user groups like a dot net user group have someone come in and kind of do like an intro to c++ for dot net programmers that type of thing i don't really know how we would do that in a podcast format and i think you know if we had the right guest on they could talk about like what kind of pitfalls

they commonly see for people making that transition that kind of thing yeah you probably want someone that's used to using well the other languages and then came to c++ and can give a clear overview of how he experienced the transition, something like that. Yeah. I'm sure it's something we could do. Well, we'd love to hear your thoughts about the show. You can always reach out to us on Facebook, Twitter, or email us at feedback at cpcast.com. And don't forget to leave us a review on iTunes. Joining us today is Jan Wilmans.

Jan is a software engineer at Promex, contracted by Thermo Fisher Scientific to work on integration of motion controller and transmission electron microscopes. He's been programming for 25 years, started with BASIC, Z80 assembly, and later C++. He's now a C++ enthusiast and open source developer and likes to keep up to date on new

C++ developments. In his free time, he enjoys playing video games and watching sci-fi together with his wife, Babette. Jan, welcome to the show. Thank you. Good to be here. You know, I love calling out the retro stuff that you used to work on, but I have to say, and I don't ever point this out really on the podcast straw but i can see behind you i believe a mac classic yeah and i i just have to mention that do you still is it a mac classic or do you still boot it up that is a classic mac it does boot i booted it only once i think when i it. It's actually my wife that is really into the Mac stuff. What you see

behind me is a showcase of some retro stuff that I collected over the years. It contains, I think, like 20 MSX computers. 20 different kinds. And some Macs. There's a

PlayStation in there. All the different kinds of Nintendo stuff. So from the classic NES to the Super Nintendo, everything is in there. So it's like your own private museum. Yeah, it is kind of growing out of hand. Yeah. I've never managed to convince myself to keep

that much around. I have my original NES that I got as a kid in 6th grade, and then the Commodore 64 that I used for CBPCon last year, but otherwise, yeah. Yeah, I have quite a bit of history programmed with the Z80, and I

got addicted to it sometime in the past, and I never really to it at some time in the past and I never really recovered from that addiction. So you said MSX, right? Was that a Z80-based system? Yes. Okay. And those were fairly small, which is why you can have many of them, right? Yeah, they are like 30 centimeters. I don't know what it is in inches uh that's like

15 inch ish yeah a little less than that a little less yeah a little less and so it's not that big it's more like a large keyboard it looks like a large keyboard so i like the commodore 64 that's the model size of it cool very Very cool. I loved your talk about C++ for tiny computers. I think it was CppCon 2016 or 2015? 2016.

16, yeah. I actually made a branch of that project that you made, a fork, to start working on it on Z80 stuff. But I didn't get much further with that yet. It was a bit of a hack anyhow, but it was fun.

Yeah, it's a real nice hack, I think. But I know some people that would be really interested to do C++ 17 on the C80, but don't have the background that I have that maybe allows me to contribute something to some kind of converter that we could write. Well, you know, maybe just to get the conversation a bit more back on track for CBPCast here, I guess.

For our listeners who are interested, the episode that we just did with Christer, he talked a lot about doing backends for C++ compilers and just published a series of articles on doing this for GCC. And I think the Z80 might be significantly more actually targetable by a modern backend than the 6502. So maybe one of our listeners should pick that up and let us know how it goes.

Yeah, would be great. I know actually there is a backend for, I don't know if it's a C80 or something very similar to a C80 already for GCC. Okay. But I never tracked it down and I don't really know. I don't think it actually works on Z80.

I just think it's a target that looks, the instruction set looks a lot like it. Okay. So it might be maybe possible to modify that. Right. That would be great for me. Well, Jan, we'll start talking to you about some of your open source projects soon. But first, we've got a couple news articles to run through uh feel free to jump in on any of these and comment okay okay so this first one uh i think we may have mentioned this before a couple weeks ago

but we're getting very close to cpp con at the end of the month and we want to remind everyone that they are looking for volunteers so i think this is open to anyone but especially if you happen to live in the seattle area it's well at this point it's getting kind of late yeah to make travel arrangements yeah but uh if you're interested in volunteering you basically get to spend i think about half your time just attending sessions and the other half a time you can do things like uh help out with registration registering speakers and attendees assisting speakers with their audio visual uh equipment and uh making announcements things like that it sounds like a pretty easy job for what you get out of it yeah and there's uh

yeah i think it's it should be fun i see the same people volunteer year after year, and I think they have fun doing it. And also, you get greatly discounted entrance to the training sessions before or after the conference if you're interested in that. I don't know the details, but yeah. So definitely, if you're around and can do it for the week or for even just a few days, contact them. Yeah, and we'll put the links to where you can send your information to become a volunteer in the show notes and one other thing worth mentioning is you know if you're the one helping out with speakers getting set up you might get to meet some speakers during your time volunteering which is pretty cool yeah sounds like an amazing opportunity i wish i would uh had have had that in the past. Only when I was a student,

these conferences weren't around yet. Well, it's not limited to students. I'm sure a lot of students are going, but anyone can do it. That's great. I'm going this year to CppCon, actually traveling to the US, especially for that. And I'm really looking forward to it. I'm really this year to CppCon, actually traveling to the US, especially for that.

And I'm really looking forward to it. I'm really having a difficult time choosing what sessions to attend, because there are a lot of tracks that interest me all. There is a ridiculous number of talks this year, and then you take into account the open sessions, it's pretty much mind-boggling. Yeah, and it's difficult to choose what to go to, to visit because it's all great i think it looks great in some way yeah okay next we have uh this announcement from molecular matters on their live c live plus plus which is a a C++ live coding tool. And Jason, I know we've talked about this sort of technology before, but I guess this is the first time that someone's made an enterprise tool

that you can just buy off the shelf and integrate with your application to get these sorts of capabilities? I don't know. Juice has some capabilities like this, right? And their IDE does. And then I went back and looked. It was Doug Binks who we talked to about live editing of C++. Okay.

And it really, like, you read the feature list, it sounds very much like the work that Doug has been doing. And what was it? Did Doug Binks do this as an open source project? Or was this something he did for his company? I can't remember. Did you look into it? I forgot to... let's see. I looked at the website and the features look amazing. So there is a

small video that they recorded to show how it works. And I guess you only need, if you're working in 32-bit mode, you

have to enable two command line switches and that's it. And in 64-bit mode, you don't have to do anything, I

think, or only a link or option maybe. And then you're just good to go. It sounds amazing. I wanted to download it immediately, but it was not available yet. Well, it looks like Doug's project is on GitHub.

It is open source. Okay. Well, just to talk a little bit more about the video, you're running Visual Studio, and then side by side, it shows someone running a video game or something else. And they make a couple of changes and almost instantly the video game updates and shows the changes that were made from the code changes. It's pretty impressive. Seeing that triggered a lot of questions for me.

How do they do that and that kind of stuff? And how will it not introduce race conditions of all terrible kinds. But they also show they have a pre-patch hook, a post-patch hook system, like there's two functions you can include in your own program so that you can target exactly where you want to have the updates.

So that sounds great for games because then you can just update it frame by frame right yeah i need to at some point actually play with one of these systems myself and have a better understanding of how it works yeah okay next we have uh this tutorial that the visual studio team put together, build your first C++ app. And obviously the tutorial is pretty basic. They're just creating Hello World.

But they go through the steps of installing the free version of the Visual Studio compiler. So if you're completely new to C++ and maybe to programming in general, this will walk you through everything you need to do in order to get set up on a Windows machine to start writing in C++. I was quite happy to see that they didn't use standard NLINE in the Hello World example. I'm like, oh no, it's Hello World. Let's see

what they did. I know that's my personal pet peeve, my personal nitpick on Hello World examples. But they don't use inline there, so our listening audience can rest assured. Yeah, I did see the one thing people were picking at them with their example is it uses precompiled headers, which is very common in Visual Studio projects, but it's not necessarily standard C++.

Well, it was automatically added by the default C++ app template. Yeah. I think people were suggesting maybe you should make a new template that doesn't use pre-compiled headers. I've seen some Twitter discussion on that also. Like, we need just a basic C++ empty project kind of example

for Visual Studio. Yeah, would be a fresh start. So that would be good. And also to not have to explain that right away. Right, yeah. That adds an extra cognitive load to the person you're trying to teach C++ to. Yeah, you don't get one file.

You get, like, five files, with a resource file and an H file. And you have to... And they read me even with I always throw away immediately. And yeah, it's not necessary. Just start with one file and then work your way from that.

Yeah, good point. One reason I like to encourage people to have like a Linux VM set up, not to say that Visual Studio is one reason i like to encourage people to have like a linux vm setup not to you know say that visual studio is bad or anything but ide's in general have this extra like several steps to test something but if you just got like vim and gcc on the command line you can make a test example program in like 10 seconds without having to create a new project and all this stuff. Yeah, makes sense. Okay, and then Jason, did you want to introduce this last article about undefined behavior calling a function that shouldn't be called?

Yeah, this is great. So I saw this going around on Twitter, I believe Reddit, I think was where I first saw this. But then Krister, our guest that we just mentioned, showed, like broke it down why this is possible. But let's just say when you're teaching C++ and you tell your students, if you invoke undefined behavior, the compiler can literally do anything, including formatting your hard drive and calling your grandma and saying nasty things about you.

They think you're joking. They think you're joking. They think I'm joking. This is an example of how if you invoke undefined behavior, it might actually erase your hard drive. And I'll just leave it at that. And you should read the article and come to an understanding as to what the compiler is doing here. I found it very interesting. I never realized the optimization opportunities that undefined behavior might have.

I also really like this bit contrived example, of course, but intentionally to show that it actually can erase your hard disk. It actually can. And I need to spend a little bit of time playing with this example. I haven't had time yet, but I want to make a version

that has two functions that are never called and see if it chooses one or the other, or if that gives you a linker error instead. Yeah, that's nice to know. Also, I wondered about if generally I would not like my compiler to assume that I know what I'm doing. So, yeah, it's more like, so the reasoning of what's happening is like, well, you probably didn't mean this because that would be undefined behavior so I'm going to assume you know what you're doing

and take another route I wonder if you can enable warnings if that kind of decisions are made I would like to have a warning in this case I think I need to look at this but I would like to have a warning in this case, I think. I need to look at this, but I would almost guarantee that Clang's static analyzer would warn you that you are calling a null pointer.

It should. I need to spend time with it for sure. It's on my to-do list. Actually, pretty high on my to-do list. But yes. I'm curious to see what it would do with uh your suggestion of having more multiple you know assignments to do it like would it just choose randomly would it choose whichever one is first i don't know or would it not choose at all and actually give you an error in that case because they can't determine what the course of action

so yes so now that we've talked very vaguely around this entire thing, all of our listeners need to go read this article and either have your mind blown or come to some new understanding and a deeper relationship with your compiler. Okay, Jan. So you have a couple of open source projects that we want to talk about today. The first one being DebugView++. Could you tell us a little bit about that?

Oh, yeah, sure. This is a project I came across. Well, actually, from my work, I use DBGView from Microsoft, from Season Turners. And I never wondered why they use it but uh it was in use when i came joined the company and um well i lived i liked it basically it was not that bad and i could filter filter all kinds of things and color all kinds of things and that was basically doing what it's supposed to do. I was very happy with it until I ran into a series of crashes, but it appeared that the application was hanging, but it turned out it was trying to write a crash dump file.

And while it was doing that, outputting all the memory that had leaked in the process. And actually, that logging, that writing of the logging, took about a minute and a half. And during that time, the application was frozen.

So not only does this give a very bad user experience, but it also gets a lot of weird crash reports that first you're doing something and then you're doing 10 other things and then you get a crash. But actually, it crashed a minute ago.

So that got me started because then I thought, okay, when I turn off this DBG view, it crashes immediately in three seconds instead of a minute. So something is delaying the process. And it turned out to be the output debug string API that was delaying the process. So that API works with a set of mutexes that interact with your program. So if you

make a poor implementation or not very fast implementation, you take the mutex, you read the buffer from one debug message, and then you release the mute mutex and then your program can actually continue so uh what they did in dbg view i think but because i don't have the source code for of that program it was it was available i think in the past but i didn't track it down um they did all the handling of the incoming messages on the UI thread. And that has its limitations. And it's usually not a problem until you start outputting hundreds of thousands lines per second. And then it starts to become a real problem.

So having said all that, I made a more efficient implementation of the program in C Sharp back then. Then a colleague of mine really liked it, but I didn't support any filtering. He said, well, I want to help you with this project, but I'm not going to

write anything in C Sharp. I didn't have any experience writing a UI application in C++. So he set up basically the UI part of it in ATL. And I brought my knowledge about the logging interface, the API. And we basically in the two weeks of Christmas of 2014, I think we hacked together this program.

And it's all, yeah, well, that got me started and went features after feature from that. Okay, so it sounds like the goal of this program is to be a better version of debug view. For listeners who haven't worked with that tool, what exactly is it is it doing is it attaching to an application that you expect to crash is that the basic idea um um they usually know um so what is the original program is listening to the what it's a typical windows

api so output debug string api it's-sharp users might see when they do a trace print line or debug print line. And in C++, you can just use the Output Debug String API immediately, so it will stay away. And so what I do with that is sort of fancy printf debugging, basically. What I find is the difference with printf debugging is that this allows you to do it from many different components of your program

at the same time without causing any race conditions that you might otherwise have in the console. So the console is typically, the printf debugging is not that safe, so all your messages get garbled up in the console. If you're doing it on multiple threads or from multiple components, or even from different processes, that will be difficult, of course, in the console. But in this case, there's the global mutex that is protecting you from, well from interfering with other programs.

And you get all your debug information nice and separated. So that's it. Did I actually answer the question? I think so. Yeah, I was curious if it's... So it's specifically messages that are sent via this debug message API. It's not capturing standard error or standard out. Yes and no.

The original program did only capture the output debug string. But this, the version that I made, you can drag anything you want into that program and it will capture standard out, standard error. And also you can drag any log file in there and it will tail the log file. Oh, okay.

And also you can mix that. So if you want to do the standard out ofone process and a log file, that is possible. It just monitors the log file for changes and the messages are coming in live. I can see this being useful in some projects I've worked on on Windows for sure. I use it for Windows. My wife is actually also a software engineer, an architect on Java, and they use it for Java as well. So it is for web development. You can just drag a URL in there, and then it also works the same way.

Oh, wow. So typically on Java environments, you have server-based server-side logging. And in the development environments, they expose that server logging on some URL, server URL, and then you have to go there and get the file and open it in some editor and then you can read it. But in this case,

you just drag the URL in here and follow it as it grows. But it is a Windows-specific application? Yes, it is Windows-specific. Okay. Any plans to port it? Well, if someone were to help me with the UI part of it, then I might port it. I was going to ask you what GUI toolkit you used,

and then you mentioned ATL, which is... Yeah, that explains it, yeah. Yes, ATL. So the thing about ATL... I actually use WTL, which is, yeah, that explains it, yeah. Yeah, it's ATL. So the thing about ATL, I actually use WTL, which is C++ wrapper on top of ATL. Okay. It's written by Microsoft. I think it's Nedat.

I'm not sure what its last name is pronounced. Stefanov, something like that. Maybe I'm mispronouncing it horribly. He actually helped me a couple of times to solve some problems. But he used to work at Microsoft or still works at Microsoft. I'm not sure. And he created that for Microsoft internal purposes. At some point, I think they abandoned it,

and it's now open source on SourceForge. And he still supports it. So I have some email contact with him, and he was very helpful. But it's actually a very nice C++ thing on top of ATL that you can use to build UIs. And the really positive side of it

is it's really, really fast. And you have no overhead whatsoever. You can do basically anything you want. But the problem with it is you have to do everything yourself because it's not drag and drop. It's all putting the classes together. And if you want something special done in your UI, the amount of controls that you have is limited.

It's basically the set that you had in VC6 and that's still the basic set. So that's it. So I also notice on your webpage here you say that you support ADB

the Android debugging console, right, for debug view plus plus. But you also say or anything else that has standard out. And I'm wondering if you do anything smart to like parse the messages or any kind of heuristics on them or what exactly to give the tabular view to the user. No.

It just comes in as it is, and there's no processing going on other than filtering and highlighting, that kind of thing. So the tabular view is, you can define different filters for each tab, and the way I use that is, I usually want a high- view of my logs so I know in basic steps what's going on. But I don't want to disable all the details

because when I run into a problem you might have to reproduce it again, but then with detailed logging and then go back and hope it happens again. In this case, I just have all the logging on all of the time. I have a high-level view, a filtered view that I use normally. And then when I run into a problem, I click the linked views feature, and then it jumps into the tab next to it in the unfiltered context. So then you have zeroed in on that part of it. You know exactly where you want to be and you have the full context of the whole logging.

Okay. One thing I noticed on the GitHub page is you have ReSharper, Backtrace and Incredibles listed as sponsors, which I don't think I've really seen on open source projects before. And they all happen to have been sponsors of the show. It's actually not a coincidence. Okay. Do you actually work with them? Are they using DebugView++? I was just kind of curious about that.

Yes. So, no, I am not aware that they use it oh they're free to of course but um uh actually i got the sponsors uh by listening to cpp cast because uh you got you made a commercial for um for all of them and um they one of the things you mentioned it was uh they some of them basically i one of the things you mentioned, it was some of them, basically, I think it was JetBrains the first that offered free license for open source projects. Okay.

Right. That got me thinking, what other things could I use to improve my product? And what other companies might be interested to sponsor open source projects? So at work, we use, at my job, we use CrediBuild. And I just contacted them to see if they were interested to sponsor a license for me.

And they said, sure, yeah, we want to do that. But if you, if I, the only thing they asked is, well, say something positive about us on the website, or negative, but anyway, share your us on the website or negative but anyway share your experiences on the website and say we'll try it and make some do some posts about

how it turned out and that's basically what I did for Backtrace also so I just asked them for a license and they got it well that's something worth pointing out to open source developers So I just asked them for a license, and I got it. Well, that's something worth pointing out to open source developers.

Feel free to reach out to the companies. They might help you out. So do you effectively have your own build cluster at home then with these tools? Backtrace, you don't need anything. So you can just inject that in your own project, and the data gets uploaded to backtrace servers. For IncrediBuild, I have a couple of PCs lying around. Maybe in the back. I'm guessing many of the listeners of this show

have a few PCs lying around. Yeah, I imagine so. But even if you don't, IncrediBuild also parallelizes builds over different cores right if you just have an eight core machine which i happen to have then uh incredi build is already speeding up your build so uh i use a more a couple of pcs here for different purposes and um i just turn if i have to uh i'm up for purposes. And I just turn, if I have to, I'm up for a night coding, I just turn them all on and they can help me build.

I like that. And of course, my wife's PC also helps. Right. So is this product still in active development? What are you working on it with right now? Yeah, it is in active development. It is a bit stalled last year. It was stalled last year.

I picked it up, I think, a couple of months ago. I think I'm really wanting to add is, I call it a timeline view. It is basically a new filter but this time it's not filtering out information but putting flags on the timeline when something occurs and I actually got that idea from an old tool by Philips I think it was they developed a thing that's called Time Doctor. And they use that, I think, in image processing or some kind of embedded application to figure out how timing things come together. So interrupts and stacks

and all kinds of things happening on their embedded device. They make a log file of that and they visualize that using timelines. And then you can see, okay, this event occurs first, and then this happens. And then, okay, then it's my problem. And every time it happens in this order, I see the same thing.

So this kind of thing is really hard to figure out from a log file because there's so much going on. And if you visualize that with a couple of blips or points or blocks or a timeline, you can really get a clear high-level view of what's going on in what order. And to make that happen, I have to create a custom ATL control that will visualize that for me. That has been consuming a lot of my nightly hours. When you're debugging an application and one run through it,

it crashes and the other run it doesn't crash, and now you've got two log files and you can't effectively diff them because they've got different timestamps in them. And I'm thinking about your timeline that you're talking about, and I'm like, man, I can think of many times where being able to overlay two different timelines, one with a crash and one without, and show me where the differences were,

would be an incredibly useful thing. Yeah. I have that experience now already with the highlighting. I now do not use the timeline thing because it's not there yet. But with the highlighting, you can already give that different events, different colors. And then I have this feature in my Deepak View++ where you can say pause and actually disconnects itself from all the inputs and then i uh put that aside start a new instance and then i run the program again and see what uh have a different situation where it actually did did not crash or did crash did just the other one

and then then put those uh filtered views side by side, and you see by the colors whether there's a difference or not. Ah, okay. Yeah, that's really neat. Yeah, that's a different way of looking at log files. Yeah. I'm looking at your list of features, and I don't think we've talked yet about linked views.

You have that mentioned? Actually, I did mention it, I i think but it's not problem i'll it's um it's uh linked views is where you have that high level view in one tab okay and then you have a filtered view in the other so you have um um i mean unfiltered view in the other and then uh you basically look at the filtered view normally and then when a certain event occurs that you're interested in, you click it, you go to the other tab and it will stay highlighted on the exact same line.

Only then you see it in unfiltered context. So that's what linked views does. I want 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, Bactrace jumps into action, capturing detailed dumps of application and environmental state. Bactrace 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.cppcast. You also work on another project called LibIdentify. Do you want to tell us about that? Sure, yes. It's a completely different story. But that's actually a very small initiative I started, but it was interesting nonetheless for me. I have this tool that I also

use that is called Boost Test UI. It's made by the same guy that helped me build the Deepak Viewer thing. He develops the Boost Test UI. His name is Gert-Jan de Vos. He was my colleague until a few years ago. And he is still, I think, actively developing it. But the thing is, it's a UI where you can drag in multiple kinds of tests. So unit tests, let's say boost test, or a Google test, or an end unit test. It supports them all or catch. So you can use the UI to run the test instead of running it on the console. And some people prefer that and I'm among one of them. So but one of the problems is you have to recompile the tests in order for them, for the Boost test UI to identify them as the kind of test framework that they are. And I don't like that.

And I also don't have, at Thermo Fisher, I don't have access to all the sources of every test that I want to run. Or I could have access, but it will be very annoying and people don't want me to change their tests. So it got me started thinking, how can we identify the different types of frameworks in a defined way without having to recompile the tests?

And that's why I started this lib identify. It basically, it's very simple. It's just one extra command line parameter that is standardized across test frameworks. And it just reports, well, I'm a boost test framework test with a version number. So from that point on, you can say, okay, it's boost test. So I know what parameters boost test takes.

So I can use all the other parameters that boost test uses. And I don't have to worry about maybe some other test framework interpreting the parameter that I passed in some different way. Interesting. So if you had luck getting... Well, do you expect the individual user to use this lib, or do you expect that the test frameworks will eventually adopt it to add these parameters?

Yeah, so I'm in active conversation, I would not say, but I have some people on email thread. So Rafi from Boost Test and Phil Nash. Of course, we had him on the show from Catch. Phil actually already implemented the library. Then there's, I hope he's pronounced his name right, Genady Civil. He's from Google Test.

He just, I think he just started working on Google Test. And there's also Marion Leperu from Microsoft. You also had him on the show, I think. And Lukasz Mendakiewicz, he's the lead engineer on Visual Studio's test integration team. So I got all these guys together

in an email thread and tried to convince them all that it's a good idea to start using this. So it's been interesting. I think the Microsoft guys are laid back. They are just waiting for me to succeed or fail.

And Phil said, okay, I'll implement it. And the other ones, the other two generally had a lot of questions and eventually was convinced it was a good idea, but I didn't see any implementation yet.

So maybe I have to put together a pull request and they will pull it in. I don't know. And I think Rafi is willing, but has just not spent any time on it, I guess. I can really imagine that it's not a top priority for them to implement my silly library.

But I'm trying to push it ahead, and yeah, it's interesting. I would imagine if your tool already does any kind of command line processing, which I know Catch does, that this probably wasn't more than maybe 10 or 15 lines of code or something to add to Catch. No, no.

It's very, very simple. It's extremely, extremely simple. And I put the GitHub repositories there, not because it involves code, but to have a discussion on it and to be able to catalog my idea somewhere. And then you have another project listed here called Open Canary? It's also very new.

I'm almost ashamed to mention it but no it's it's at this point

really not much to talk about but it is initiative to

gather scripts that could be integrated in a continuous integration

system in order to search the log files for common problems, such as failing, what do you call it, incremental build. Okay. So I thought, well, if you can detect, if you just build once and then build it again,

and the second time it builds something, then an incremental build is not correct. There's something dependency missing or something is happening that's not correctly doing an incremental build. So that is one of the examples that I thought of that would be really generally useful to integrate in a continuous integration system that would give me an early warning when something fails or someone messed something up. So I've got more. I don't have any details right now on the kind of tests,

but it's that kind of thing that you want to check every night. But it's not per se a Jenkins plugin or anything that's standardized right now that I wanted to share with the world. I think I can look up some, uh, I got a list of, uh, examples of the things that I wanted to check. Okay. Give me a minute. Sure. Yeah.

Here it is. So things that I, uh, um, came across where I work a lot with COM interfaces. And one thing in COM interfaces is that you have to have a unique GUID for your interface or class. And if you don't have that, then it causes all kinds of trouble registering the interfaces. And normally, when you create a new interface, you should always generate a new GUID. And you can tell that people as many times as you want, but they still will forget it at some point. And so one of the scripts that I wrote was,

well, just check the uniqueness of all the GUIDs that I have. And report that as a build failure if it's not unique. Oh, that's pretty interesting. Other things were things like having all compiler warnings on. So I actually report projects that don't have level 4 warnings for Visual Studio set. I report that as a warning in itself.

I like that. There's two more things that I can think of that are really active for me right now. It's using namespace and header files. It's a build failure. And I think the other one is using make unique, but not the standard make unique.

So that's a red flag for me. So that's a warning. So if you have some, if you remember before c++ no in c++ 11 i think but before visual studio 2013 for me i work with visual studio there was no you make unique i think it's uh that was added in c++ 14 technically okay right And so before Visual Studio 2013, it was not there. Right. And then there were basically two options.

If you wanted to have it anyway, you roll your own, or you use Boost Make Unique and use Boost Chat Pointers. And from where I stand, I think both are obsolete now. And so I report those as warnings. Right. Makes sense. You know, I still want to come back just a moment here. I think that we should petition the compiler vendors to make a default warning that is you have too few warnings enabled. So if you compile with GZC or Clang with no warning flags or Visual Studio with no warning

flags, that it would just warn no warnings enabled. That would be spectacular. Yeah, that would be a really good feature. Or even say, well, you don't have any warnings enabled, but there were actually 51. Just to give you a count.

You're currently ignoring 51 warnings. If you get up to 5,000 there, I think they will draw attention. Then it becomes a compile error. Error, we detected 5,000 warnings and you didn't have them enabled.

Refuse to compile. Yeah, that would be good. I don't think we'll get any traction on that, but we can hope. I think you have a backwards compatibility thing there. I have noticed, actually, there are a few cases

where Clang will generate warnings even if you don't give it any warning options. Nice. And I'm happy with that personally. I think that's cool. Yeah, I think in retrospect, you should have warnings by default instead of having to enable them.

Right, you have to disable the ones that you don't. But getting a community consensus on what are actually the warnings that should be enabled by default would be nearly impossible probably yeah it's nearly impossible to get five people to agree on a command line parameter so this will be a challenge i think so one other thing uh you mentioned when we were talking offline was an interest in the work on C++ executors. And I don't think that's something we've really talked about at all.

But I was wondering if you could share what you've been observing with executors in the steering committee. What's kind of the current status of that? Yeah, it's actually a long story. And there has been a talk by Detlof Vollmann in 2013, no, 2015 CppCon, that was actually called C++ Executors, a long story. Right, I recall the title of that talk. Yeah, it is becoming a bit of a, I don't know, a problem, I would not say, but there's so much to those executors

and there are so many different ways they could be used or implemented. It's hard to know where to start, actually. But currently, maybe I will not start from the beginning, but currently there's the concurrency TS by Michael Wong, or at least he's promoting that, or he's championing that. Championing that, yes. And he proposed now to make the executor TS a separate TS from the concurrency TS. Because only the executors themselves are so beefy that it would not be constructive to have it in one TS. So having said that,

maybe for the people that are not into executors, maybe a short detour and say what executors are. And in the view of Michael Wong, that they are things that sit between a task and let's say the CPU or whatever you're running it on. The same way that iterators sit between your algorithms and your container. So you have some tasks you want to execute. You want to have some work done. And you might have a GPU that can do it,

or you might have several CPUs or a whole farm of CPUs that can do it, and you might or might not be able to paralyze it. But from the point of view from the developer, it doesn't really make a difference. I would just want to get a job done. And depending on available hardware, you might be done faster if you do it a different way. So this is something you can use an executor for. Because you can just

say, I have this task. It can be paralyzed if you want, but it doesn't have to be. And then it can run on one thread, or it can run on a million threads if you want. And it's up to the executor to figure that out, to see what platform you are on or maybe if you want,

you can choose a specific kind of executor to have it done in a certain way. Well, there's a lot of discussion on what should be the exact interface for that in the STL. So as a very first example, I would say, let's say standard async. It now takes, I think, a way to execute it or either deferred or async it now takes i think a way to execute it or either deferred or async which is basically spawning an std thread and the way michael wong tells it the executor would be another first

argument to that std async so then you would have std async an executor and then a task to run that's one way to do the interface and you could have an executor that does that work on a gpu or something else and but that is up to you and also it could be paralyzed or not. The way I see it, they tried to cover all the use cases that they found. And I think it will take a long time to standardize it this way, unfortunately. I guess that's why they want to pull it apart so you can get concurrency and continue working on executives. So the current, I would say the current status is they're working on it.

And I think the work is being aimed for C++20. And I would be thrilled to have it in C++20, but I have a hard time believing that we'll make it. Okay. Well, is there anything else you wanted to mention before we let you go, Jan? Do you have a website where people can find you?

I wanted to mention one thing. In the DebugView++ repository, there's a small library called Cobalt Fusion. It's extremely small, but it contains an executor of sorts. It's nothing like the thing that Michael Wong describes, but it's my own interpretation. Now, it's actually not even my own. It's again by Gert-Jan de Vos, and it's his interpretation of the executor TS from a couple of years ago.

But it's very useful. It's a wrapper around an STD thread, you could say, and it's a queue of tasks that you can set up. And then you can say, well, call, do this work, and then do this work, and then do this work, and then be done with it. And you can either wait for them, the calls return futures that you can wait for, or you can chain them by putting the future in a new call, new Lambda, new lambda,

and posting that again as new work. So it is a kind of simple but effective way to get that. The thing that I talk about with executors is having the.den on the STD future. And the way this is implemented, you can actually sort of do that, but not quite as effectively, not as performant as it could be.

But you can get that done. You can execute some tasks, and when it's done, it will call the next task. Sort of a continuation kind of setup, but in a very cheap and lightweight way. But as I said, it is not as nearly as you don't pay for it, you don't use kind of strategy. It's not you pay for it, whether you want it or not,

or not in this case. So I wanted to just call that out and say, well, anyone is free to use it. But I know I use it a lot. And I see that basically all the concurrency problems that I had previously before using this went away, because I'm now just deferring the work onto the executor and I don't need any mute access or anything else, synchronization methods

to let my application do the work because it's all happening on one thread. Cool. And where can people find you online? Twitter, GitHub? Yeah, on GitHub. I have my GitHub page. It's just my name, which I guess is hard to remember or pronounce. But you can find it in show notes. And it's Jan Wilmans. It's also my Twitter handle, which is basically not helpful. But my website is easy to remember. It's nullpointer.nl.

Okay. So you can find all my projects there, and also my Twitter is on there. Okay. Thank you so much for coming on the show today, Jan. Thank you. It was nice to be here. Yeah, 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.