CppCast - Clang Power Tools and C++ Myths

Episode Date: February 5, 2021

Rob and Jason are joined by Victor Ciura. They first talk about different ways to filter a C++ container and a blog post on the Visual C++ blog from the Diablo 4 development team. They then talk to Victor about the Clang Power Tools plugin for Visual Studio which has recently been made free for both open source and commercial use. They also talk about C++ Myths. News 12 Different Ways to Filter Containers in Modern C++ More_concepts library Blizzard Diablo IV debugs Linux core dumps from Visual Studio Visual Studio's Native Debugging Framework Tutorial Links Next steps for Clang Power Tools C++ Mythbusting with Victor and Jason Sponsors Visual Assist

Episode 285 of CppCast with guest Victor Chora, recorded February 3rd, 2021. This episode of CppCast is sponsored by Visual Assist, the well-known productivity extensions for Visual Studio. Visual Assist speeds up development with features like smart navigation, code inspection and suggestions, powerful refactoring commands, and a whole lot more. Even spell checking and comments. Start your free trial at wholetomato.com. In this episode, we discuss debugging Linux core dumps in Visual Studio. Then we talk to Victor Chora. Victor talks to us about Clang++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today?

I'm all right, Rob. How are you doing? Doing okay. You have any news you need to share today? I don't think so. Usually that's a prompt for me to share something that I'm supposed to share, but I don't know. No, I wasn't sure if you had anything you were working on that you wanted to talk about okay very cool uh well then at the top of every episode i threw a piece of feedback uh this week we got a tweet from antonio natilla on twitter and he wrote very interesting conversation i have already appreciated some of klaus's talks through cpcon videos and i ended up

appreciating this faster take on solid and good design. Thanks to you all for the content. And yeah, it was great talking to Klaus again. I'm surprised we have gone that long without talking about some of these core design principles

of software development that are used very heavily within C++ programs. 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 cppcast.com. And don't forget to leave us a review on iTunes or subscribe on YouTube. Joining us today is Victor Chura. Victor is a principal engineer at Cafion,

technical lead on the advanced installer team and a Microsoft MVP. He's a regular guest at the Computer Science Department of his alma mater, University of Criva, where he gives student lectures and workshops on using C++ STL algorithms. Since 2005, he's been designing and implementing several core components and libraries of Advanced Installer. Currently, he spends most of his time working with his team on improving and extending the repackaging and virtualization technologies in advanced installers, IDE helping clients migrate their traditional desktop apps to the modern windows application format. MSI X.

One of his hobbies is tidying up and modernizing the agent code base of advanced installer and has been known to build tools that help this process, including client power tools. Victor, welcome back to the show. Hi, thanks for having me back. It's nice to be back after almost three years now.

Oh, wow. Has it been that long? Okay. Wow, time flies. Yeah. What do you mean by being a regular guest at your alma mater? I'm usually doing guest lectures and workshops. I have a few friends, professors,

basically get students in touch with concrete examples and applications of computer science principles. So I regularly do guest lectures and workshops. I do summer school with various topics. So I'm basically there about two or three times a year okay and i've been doing i've been doing that for six years now i think but since you you do speak at conferences semi-regularly and uh and and and go is speak at your alma mater like this i was curious have you ever done any professional training i don't believe i've ever heard you mention no no no have you thought about it?

No, I think now is the first time. Okay. No, I haven't thought about it. The closest I get to this is onboarding new hires and mentoring junior engineers joining the team and working with interns that join our internship program every spring and summer. Okay, very cool. So that's the closest I got to this.

All right. Well, Victor, we've got a couple of news articles to discuss. Feel free to comment on any of these and we'll start talking about C++ myths and maybe about Client Power Tools too. Sound good? Cool.

All right. So this first one we have is a post on C++ stories. And this is 12 different ways to filter containers in modern C++. And I thought this was a good post, kind of showing how much simpler some of this filtering code can look if you're able to use C++20 ranges or concepts.

Yeah, I really enjoyed this article by Bartek. It's a really good one. But I was scrolling through basically the evolution of the filtering mechanism presented there. And I was getting right to the end where he got into parallel versions of the algorithms. And it was like a cliffhanger. That's an interesting bit I want to see a follow-up on. And he promised a follow-up post on that. So I can I want to see a follow up on. And he promised a follow up post on that. So I can't wait to see it.

Cause I've done some experiments myself with parallel algorithms and comparing, doing some benchmarks, comparing them with the sequential versions and the trade offs and more times than I would like to admit it was underwhelming. So yeah, I'm really interesting to sing this part but a very nice algorithm very nice article that is yeah and in this example of doing a filtered copy from one container to

another using a parallel algorithm I mean I'm pretty sure the only thing you can actually parallelize there is the actual copy of the object. Yeah, you can split the work basically, if you're just talking about filtering here, and you can, I think you can do chunks and filter independently too. But then you would have to create the merged version. Yeah. Yeah. And whatever, and then merge them. And that seems just, yeah, but I think the whole premise, uh,

how he formulated the premise of this article is, uh, doing it in a more functional style. So basically returning a copy that contains the, the filtered out elements. So I think that's the idea was, uh, leveraging more composition and doing it in a more functional fashion.

So I see his angle here. Okay, next thing we have is a GitHub library. And this is more concepts. Jason, you want to tell us about this one? Yeah, it's just a well, it's just a library of concepts for C++20. That's really all there is to say, but most of them are around containers, random access containers, sized containers, clearable container. I don't know, could be handy. I just like seeing people starting to adopt C++20 stuff personally. Yeah, I guess I didn't realize that these were

like these type of container-based concepts were missing from the built-in ones we're getting from the STL. We're not getting very many concepts in the C++20 STL, relatively speaking. Yeah, even in Bartek's article, he played around with the concept of having a pushback on the container.

So they kind of tie in together nicely. Yeah. I don't know. I'm split regarding this kind of approach in providing a plethora of supplemental concepts for the STL. I think we have to strike a balance between utility and being overwhelmed or basically producing too many, too special purpose concepts that aren't actually usable in many contexts. I think Bjarne warned about this in his keynote in 2018, if I remember, talking

about concepts and he was worried about people inventing concepts left and right just to cover and basically providing nicer API level checks and nicer error messages just for the heck of the API boundary. I don't know. I think the jury's out on this one. We have to gain experience actually using them in real life before we can distill best practices there. Yeah.

And I have the problem of the compiler I actually need to do work on doesn't have good concept support yet, so I can't really apply concepts in my real world work yet. Me neither. Not yet. Just experiments. Hopefully it's coming.

Alright. And then the last thing we have is a post from the Microsoft Visual C++ blog. And this one is actually from a guest author from the Blizzard Diablo 4 development team. And this is Blizzard Diablo 4 Debugs Linux Core Dumps from Visual Studio. And it's amazing that you're able to do this now in Visual Studio. So if you're not used to dipping into a Linux environment and using GDB to debug a core dump because you do most of your development in Visual Studio,

like the Blizzard team is saying they do, then being able to do this in Visual Studio is going to be a huge time-saving, and that's kind of what this article is all about. One thing I wanted to point out that the article mentions is parallel stacks. This is something that I only found out about myself a year or two ago. Any Visual Studio user who

doesn't know about parallel stacks should go and check it out. Anytime you do a break-all or you're debugging something like a core dump, like in this example, you can look at your list of threads, a textual list, and try to pick the right call stack where something may have gone wrong. But the alternative is to use parallel stacks, which gives you kind of like a graphical view of all your threads and each one's call stack. So the nice thing you can do with that is kind of just ignore all the smaller graphs because they're probably just waiting for work and look for the big call stack graphs because that's where probably something is actually going wrong. That's probably where your problem is. And most of the time I've used parallel stacks. I go into it and there's usually one or two of these bigger call stacks. And that's always where the problem is, where you want to go looking. So I really wanted

to highlight that. And anyone who uses visuals should check it out. Yeah. Bits guessing from a combo box. Yeah. Yeah. Because the default view is a very slim combo box with just the entry point name. Yeah, I had no idea this was a thing at all. Yeah, it's a fairly old feature, but lesser known. Yeah, that's why I thought that was worth highlighting. But yeah, anything else you want to point out with this article, either of you? I was just about to say that on a related note of lesser known but older Visual Studio features, Bartek Filip again published, I think a week ago, another article on Cpp Stories on his blog,

on Visual Studio visualizers and the fact that very few people know that you can customize the debugger experience in Visual Studio and define with the help of some XML files and predefined schema, you can define the layout of your custom objects and how you want them to be surfaced in the debugger when you hit the breakpoint. What exactly from the innards of your complicated data structure, how exactly do you want to present that easily in the debugger view in the watch window or something like that. And the Visual Studio team actually did that for the STL types and you can do that the same thing for your types. So Bartek has a very nice tutorial.

I've actually never seen a proper tutorial, proper intro describing this. Maybe we should link that in the show notes as well. Because it's a nice way to get started if you actually plan to incorporate that. Very few people actually know about this feature. Yeah. I think we mentioned a few times before, but I'll definitely put a link in the show notes. Qt has their own visualizers that you can install as well if you do a lot of debugging with them which is huge since it's got such a huge api service yeah and i'm guessing that works well with the

mock compiler and everything yeah and i you know to be fair i don't know if i've ever actually used them or installed them i just know they exist, I haven't played around with Qt since, well, I think 2010. It's been a while. Okay, well, Victor, can we start off by maybe getting an update on Clang Powerful, since that's why we had you on the last time on the show. Yeah. Back in late 2017, I was very exciting coming on CppCast and talking about the brand new Client Power Tools. I was

very, very excited back then and I still am. I have some news. We've come a long way since then. We've been working hard on adding tons of features and functionality to the suite of tools because there are actually more tools now aside from the Visual Studio Extension and scripting components. And in 2019 we actually, we were very serious and

set out to work full time on this. And we had a dedicated team to support this product because it started like an open source hobbyist kind of thing that we developed to consume and leverage internally. And we were dogfooding it and it soon gained a lot of traction in the community and people starting coming up with ideas and bug reports and suggestions and feedback a few patches but we did most of the work ourselves

so we basically were victims of our own success and we were overwhelmed by the work that we had to do just for this tool and it far surpassed the internal needs that we had from this suite of tools. So we basically said in 2019, let's hire a full-time team to work on this. And we basically worked ever since to deliver on those promises and all those suggestions and feature requests and reports. And I think we've reached a level of maturity and it's a very strong suite of tools. We just this week announced a separate standalone tool

for Clang format editor and Clang format configuration. So many people have a hard time actually figuring out the appropriate Clang format format or settings suite to match their codebase. I think Jason did some experiments a few months back trying to figure out some tools that can help with these heuristics and actually figure out a close match for an existing code base. We've delivered a lot of functionality in this area and just recently we just shipped this

separate update that's not tied to Visual Studio so it can be used independently. I think the biggest change that materialized at the beginning of this year is that Clang Portals is completely free now, free for commercial use as well. It's always been free and open source for non-commercial use. Well, starting 2021, it's free for commercial use as well.

So no more signups, no more licensing, no more anything. So we're hoping that this change will bring back more people to actually use the tool at work, both in personal hobby projects. And we're hoping that they can leverage the power of the LLVM framework and the power of Clankt ID and actually find stuff in the code base actually not worrying about the tooling and the infrastructure and just worry about fixing the bugs and the problems they find in their code base

and we're happy to be a part of this tool chain and helping people. So do you still have a full-time team devoted to working on it? We still have because we're using the tool internally so we have no plans to abandon it. So it's open source but we're gonna keep pushing and doing the backlog stuff that we have and improving it and adding more stuff and accommodating feature requests as always. And what I think the biggest win from this experience from 2017 up to now is that we've basically raised awareness in the community of Windows developers that were not accustomed to actually leveraging these kind of tools like Clang, LLVM tools

in general, Clang Tidy. And now these things became mainstream for Windows developers as well. We're seeing a lot of coverage there in the box. The latest Visual Studio versions actually come with Clang format and pretty good support for Clang tidy. And it's not on par with what you can find in Clang Power Tools in terms of customizability and what you can actually do in workflows and in automation, but it's pretty good. And I think this raised the bar for all Visual Studio users whether they use Visual Studio bare bones

or actually leverage plant power tools. So I'm pretty happy that we now have address sanitizers in Visual Studio, starting with VS 16.7. We have 64-bit support as well. And with 16.9, it's going to get even better. So I'm pretty happy that basically the Windows developers started to leverage and dip into the pool of great tools that have been built and leveraged

on the Unix part of the ecosystem. So I'm pretty happy to see great LLVM adoption on Windows. So what features though that Clang Power Tools offers sets it apart from the Clang format and Clang tidy features that are built into Visual Studio now? I would say the first thing that you might notice

is the workflows, the user interface, the ease of use and the ease of use in configuring it. You don't need to manually fiddle with config files and know all the flags by heart. And it basically does everything behind the scenes and you have a very simple intuitive user interface

over that thing. And on the second part, I would say helping with automation and continuous integration efforts. For example, our PowerShell scripts actually help to do this job on build servers. We actually do pipelines and jobs that we have on GitLab and we have runners running jobs under Clang Power Tools and we do regular builds and we do linting and we do transformations at scale which are much easily done outside the IDE. So if you want to do stuff at scale, it's much easier to do it outside the IDE

and you need to be able to do that easily. So, and you do have the power that you can drill down and configure stuff and tweak the knobs, so to speak, to make it fit your needs. So you can either use it as a high-level tool, like defaults are good for me. I'm using it as a plugin for Visual Studio. So it's beginner friendly, but you can get down to using it as a power user from PowerShell script and everything. And we use it on all the spectrum.

So every developer on our team actually has the plugin installed and we actually have gitlab runner jobs that actually run automated scripts over it i think it it helps for us it was a game changer and from the community reception we've seen it helped many other teams yeah that sounds great and it's really exciting announcement that you're making it freely available for any type of developer using Visual Studio now. Yeah. Awesome.

I want to interrupt the discussion for just a moment to bring a word from our sponsor, Visual Assist. Visual Assist is used by serious C++ developers across the world. It's got great code generation. Do you need to implement methods from an interface? What about changing a pointer to a smart pointer, even an Unreal Engine smart pointer?

Adding a symbol you've typed but haven't declared? Visual Assist will do these and much more. Plus refactorings, more powerful than the ones included in Visual C++. Or detecting errors in code and suggesting useful corrections. Or navigation, helping you move anywhere in your code and open or locate what you need. Or even the debug extensions. Visual Assist is written by C++ developers for C++ developers. It includes everything you need and nothing you don't. It has a low UI philosophy. It won't take over your IDE, but will show up when useful. It's there to help, not to advertise itself.

Visual Assist is relied on by the developers building software you've used. Whether that's office suites, operating systems, or games, software you use was built with Visual Assist. Get the same tooling for your own development. Visual Assist supports Unreal Engine 4 and many versions of Visual Studio, including VS 2019 and Community. Get it at wholetomato.com. So I know Jason and you, Victor, recently did a stream together.

I unfortunately did not have a chance to watch it. Do you want to tell us a little bit about these C++ myths? Oh, that was a lot of fun. I had this idea a few weeks back, and I think I mentioned it on Twitter, and Jason thought it was an interesting idea. It was actually something he did a few years back in blog post form. Got it. Yeah. Yeah.

Exploring some myths a few years back. So we basically brainstormed offline. We brainstormed on the format and what we would like to see and what would people like to see explored there. And we made a plan. I made a list and we brainstormed over a few items, a few candidates. And basically, it's inspired by things I've heard, discussions I've heard, things, discussions I've seen, debates in code reviews, questions from students whenever I'm doing a guest lecture and I talk about C++ and I talk

about language evolution and I talk about algorithms, mostly about algorithms, and questions I get from students, questions I get from interns when we do internships or when we do onboarding for junior developers. And mostly controversial stuff that you see in code reviews and stuff that's not always clear-cut, because there are many things that are clear code smells and are clear best practices from years of experience and very good presentations and very good and articulated cases and examples and good blog posts that you can refer to or good conference talks that you can point out to. But there are some cases which are, let's say, debatable. And we tried to tackle a bit of all. We did some obvious things, at least for a seasoned C++ developer. We did some controversial things and we tried to engage. It was a live stream

so it was a lot of improv there and we tried to engage the audience and we had quite a few people actually online with us and very engaging over the the youtube live stream chat so we had a lot of lots of suggestions there and we were we actually set ourselves to be very flexible and follow and let the discussion go either way and we we did a few tangents and we explored a bit of gnarly corners of the language and it was quite a lot of fun and the early feedback we got was very good. So people were entertained, people learned new stuff, we learned new stuff, at least I did. stuff i did at least i did so basically jason was the was the driver and i was keep throwing him balls and and it was um it was a very very entertaining experience and i think we learned

a lot and uh from what i gather people want to see more okay Okay. Yeah. Have you gone back and read all the comments just out of curiosity? YouTube comments are a sensitive subject. Yeah. It's a mixed bag, always. Except for the live comments. I personally have a policy of not reading the comments. Yeah. But the live interaction was... the live interaction i followed very closely yeah yeah the live interaction was very very good but the offline youtube comments are well your average youtube comments yeah it can be a dumpster fire so obviously uh you know listeners can go and watch the whole stream i'm guessing this is on on your YouTube channel now, right, Jason? It's on my channel, yeah. Yeah, it's a two-hour recording, so brace yourselves.

Yeah. We got comments back-to-back that said, there's no way I'm going to watch two hours. Give me the TLDR. And another one is saying, this is perfect. I love this format. Thanks for sharing. Yeah, I want more.

Yeah, you cannot satisfy everyone um some people want bite-sized information like shorter format things some people like the improv long form streaming format so yeah cannot please everyone we actually had requests to do a blog format kind of thing. Some people prefer the written format. So I honestly, yeah. JOHN MUELLER, I can't remember what questions we actually discussed. Do you recall, Victor? VIKTOR CHERVAKISIMOVICSKAYA, I have the list right here.

So I highlighted the stuff we actually, because we had a huge list. JOHN MUELLER, Yes, Victor came up with like 150 things that he wanted to eventually cover and i think we covered three no there were more than three so okay we covered weird standard move pattern like moving the same thing twice in a function call. We covered the uniform initialization and some of the uglier parts of that. We covered pass-by value for sync arguments. That's pass-by value versus making the multiple option of... Yeah, multiple reference and R value reference. Oh, okay.

Yeah, yeah. Basically, the sync pattern. Hand-rolled string processing versus standard Regex. We actually started with that one. That was fun. We talked about standard optional and wrapping stuff in optional and optional chaining and monadic interface for optional

and performance worries in codeblood yielding from using optional. What else did we talk about? Well, obviously, listeners should go and watch the stream if they wanna see all of these, but do you wanna pick out one or two maybe of maybe some of the more common myths that you hear about from your other team developers? Or would you go over some of the ones you didn't talk about?

Yeah. I have honestly no idea why you picked the order that you did, if there were things that were higher priority for you that we didn't cover? I basically tried to string stuff together that was somewhat related but it definitely wasn't like a top five things or something like that. I added more stuff to that document, Jason. Okay. Just today we had a discussion in Code Review around strong type wrappers. I don't know if people are very familiar with the concept. Jonathan Bocara had a very nice series of blog posts about named type and he has a library called named type for wrapping stuff in strong wrappers for safer function calling and safer overloads and also Bjorn Faller has a strong type

library both are open source and we actually had a discussion today in code review around some tricky situation where the wrong overload was picked. A new overload was added to the overload set. And in some existing code, the wrong overload was picked by accident and caused a bug. And we talked about how might we have avoided this, going back and redesigning the API and thinking about various gnarly stuff.

And of course, function argument default values were involved. So that was ugly. And this whole thing came up actually today and talked about it. So I would want to discuss this openly too. Yeah, building strong type wrappers for function arguments. Yeah. I feel like virtually every guest we've ever had on the show has had some sort of strong type library.

Well, I don't. But I like this, too. I like Bjorn Faller's strong type library Library and Jonathan Bucara's NameType. They're very lightweight, very simple to use. So either one, pick your favorite. I feel like if it's something that everyone or many people have reinvented many times, perhaps it is time for us to get a standardized way of doing StrongType devs. I've brought this up on Twitter before,

and apparently the first time that came up was in 1997 or something like that in the standards committee. And no one can agree on what a strong type def would be, I guess. Everyone has their own arguments of what this would mean. And so therefore, it just constantly gets dropped from consideration and how much functionality to offer because you can go and basically do a very complicated wrapper and add all bunch of whistles on there to satisfy various needs and various scenarios and people might find it too difficult to use or maybe invoke like a myth like this thing using this thing is costly

generally it's a load for me so it's a it's a thin line between something being useful and people seeing it as overkill like it's not worth it i just want an integer here i just wanted the boolean why are you pushing this whole monstrosity? It's a thin line between a lightweight thing that people want to use and something that fits all scenarios. Library designers have a tough job. So what was the conclusion in your code? Did you change the API so that it wasn't a problem in the future in in our case it was a it was an ugly mix uh and and one that i already had on on the list there uh it was a a conversion constructor that was not explicit ouch and some overloads that had default arguments for some of the default values for some of the arguments. Some overloads had some defaults. Yeah, it was an ugly situation. And we basically fixed the API and yeah,

we got rid of the problem. But going back, I think if we had proper vocabulary types for those arguments, the problem could have been avoided. Yeah, but it's hard. It's a hard sell because people say, this is a plain Boolean value. Why are you making me use a strong type here? So. Well, I mean, given all the conversions that are possible,

I'm not gonna do with you. Yeah, so it's in some situations it's a hard sell, but in our case, the fix was actually easy. But in our case, the fix was actually easy. The problem was ugly. The fix was easy. I take it you are not in a situation where breaking your ABI is a problem. No, it was a component that we consumed ourselves. So it was not a problem changing that ABI.

Well, since it's a topic that we bring up all the time anyhow, how would you feel like in your Visual Studio user, let's say the next point release of Visual Studio or the next 2021 release or whatever, just breaks all the ABI and you have to recompile all things and can't reuse your existing library. Is that a problem for you? I'm for it. You're for it. Okay. I mean, I mean the. Break everything. I mean the compile from source camp. So you don't rely on binary blobs from third-party vendors that went out of business 15 years ago. We have a very limited set of libraries

that we actually consume in binary format, but those vendors are still working on it. I'm trusting them to upgrade I like how the past three versions have been ABI compatible with each other 2015 17 19 but I'm fine with breaking it and maybe the next two or three can be compatible with each other yeah it's time for breaking release they've been pretty good so far, so I'm waiting for the breaking change release. Right, and in previous to 2015,

correct me if I'm wrong, but each version was a breaking ABI change. Yeah, basically, yeah. Yeah, that was the world we lived in. We just never assumed that we could use libraries from a previous compiler. Yeah, and it was a simpler time. People just didn't make assumptions. They programmed defensively. They asked for source code.

On the other hand, you have, let's see, it's the C++ coding standards from Sutter and Elegs and Rescu, which is from that kind of timeframe, early two thousands where they effectively say, don't have C plus plus types on your library boundaries. And use extern C everywhere or use, well, you see types used, you know, like basically,

yeah. Like you don't pass a string across function across library boundaries. And when I read that, I'm like, okay, that's one rule I will not be following. Because to me, that just broke the point of C++. Like if I can't have a library that uses strings and vectors natively, then what the heck am I using C++ for? Well, you would be surprised. We have a bunch of those, like external C interfaces,

and we have a bunch of libraries that we actually consume through a C interface. But there's reasons to. It's a pain. Yeah. I'm not saying throw that out entirely. I'm saying I don't want that to be my norm unless there's a reason for that to be what I need to do. Yeah. At least you don't have any ABI worries there.

Right. And you don't have any ABI worries. So I guess it goes both ways. C is still the lingua franca of Interop. Yeah. Unless you like com. For people just listening in, Jason just went cross-eye. Well, cross-platform.

I wrote some column objects in C++ in 2000 yes in 2000 and I needed to expose a an object hierarchy with inheritance

through to VB6 for consuming with VB6. And I could not figure out how to get the com interface stuff to be properly inherited and reflect this inheritance in VB6. And I posted a forum question

to one of the Microsoft forums and got a response back from an MVP, actually. It was my first ever intro interaction with MVP who explained that I needed to templatize the, the inherited type. And I don't remember the exact details now at this point, but that completely blew my mind because I didn't really understand anything about C++ at all at the time.

Well, yeah, the interaction with COM, it got a lot easier nowadays. And we have simpler activation models and basically the usage is much friendlier. You can

still do the old stuff, but I think it's easier now. What actively uses COM at this point? Everything on Windows. Oh, really? If we're talking about I think it's easier now. What actively uses COM at this point? Is it... Everything on Windows. Oh really? If we're talking about modern Windows, WinRT stuff, everything is built on top of COM. It's there but it's hidden, right? It's hidden, yeah. You have a nice layer and you have language projections and now we have very nice language projections for Win32 APIs, for WinRT APIs and everything.

So it's a very nice projection, but underneath it's all COM. It's still COM all the way down. It's COM all the way down. Yeah. And COM is the technology from like the 90s or something. Yeah, like a long time ago. Yeah. And comm is the technology from like the 90s or something. Yeah, like a long time ago. Yeah. Well, I've done quite a bit of comp programming in the last 15 years or so. And it's

yeah, it's not that bad. It grows on you. I like it. Well, that was the last time I actually had to write my own comm objects and C++ that is was back in 2000. And yeah, never touched it again after that after I left the VB world. As a spec, I think it's a it's a very, very well designed thing. COM is a very well designed thing. It's very flexible. And I think being the fact that it's being leveraged in modern APIs and in current software, it's a testament that it's being leveraged in modern APIs and in current software, it's a testament that it's a well-designed API and survived the test of time, basically. It's very flexible.

Now that we've gone this far down this road, Victor, can you describe to our listeners what Calm is? Yeah, we haven't actually said. Yeah, I think... It's like the matrix. You have to experience it for yourself. Yeah, yeah.

I think... It's like the matrix. You have to experience it for yourself. Yeah, yeah. I think the simplest explanation is that it tries to model an object, an API surface that is independent of the types and their properties and their functionality and basically exposes what can you invoke and what are the types and the type layouts that it's a means of describing all this information there's actually a language behind all this thing it's called the middle middle or I don't know how to pronounce it. Okay, yeah. Yeah. And WinMD is the modern format for describing this kind of type information.

And you can describe this independently of the actual implementation and independently of the hardware or where the actual code resides. And it's an abstraction that allows you to talk to objects and call functions and pass values and marshal information regardless of the fact that the object you're talking to is in the same process as you or in an external process or on a different server. It's an abstraction over API, over hardware and it allows you to flexibly describe APIs and call methods

and share data across object boundaries. As a design, I think it's a very beautiful thing. It has a lot of ugly words and details, but as a design, I think it's a beautiful thing. You were saying, Jason? Sorry, I tried to interrupt you three times there. It just seems like it's very familiar sounding, like the same kind of technology has been reinvented a few times, like Korba or Mock is pretty similar, or the interface files the.i files that are used for by swig for generating different language bindings um yeah it's yeah i think the the same concepts have been around the

block for 30 plus years now so at least yeah yeah and we've seen various incarnations of them, and some of them survived the test of time, some of them are for the history. But I think as a design, this was a tremendous success, and the fact that the whole Windows ecosystem is built on top of this kind of stuff, it's amazing. Yeah. And it's a very efficient technology. It's not some kind of abstraction layer

that actually incurs performance penalties or anything. Well, it had to run on computers 30 years ago. Yeah. It was designed back in the day when people actually cared about performance. Because they had to, not because it was fashionable. Right, right. Do we want to bring it back to the C++ myths at all?

Do you have any more myths? Maybe are there any related to COM programming? I don't know. I actually don't have any myths related to COM here. It's all true. No myths. No myths around COM. Just history.

Right, right. So have you gotten any other feedback outside of the YouTube stream, like from coworkers or friends or anything, on the myth-busting concept you put together? Yeah, a few mentioned that they liked it, and they came up with some suggestions, but I think generally people, I think with regard to this topic, falling into camps, some people are reluctant to propose something because they're afraid of how it might be interpreted in terms of,

is this really a myth? Is this like a popular opinion kind of thing? I'm afraid to take a stance on this. I'm afraid if I present this as a myth candidate, it might be interpreted like I'm disagreeing with it or I'm agreeing with it. Some people are in the camp of being reluctant to propose stuff in this category. And some people actually do propose very good suggestions, but they're very hard to generalize.

They're very hard to present in an abstract, simple setting without taking them out of context, basically. So it's very difficult but the idea in general i see people enjoying this the idea of debunking common idioms or basically investigating stuff that that they might have seen on their own and i think they love the fact that just as they have for example with let's say a c++ weekly episode they they might use it as have, for example, with, let's say, a C++ weekly episode. They might use it as a reference. For example, hey, about this topic, there's a C++ weekly episode that talks about this.

And we have a few examples and we see what happens if you do that, what happens if you do that. So it's nice to have a reference to anchor your discussions around. You don't always have to necessarily agree with that reference, but it's a good anchor point to start a discussion and to reference it as a catalyst for a discussion. And I think they're looking for something similar here. They're looking to identify in this list of myths,

like we call them, they're looking to identify patterns that they actually encounter identify in this list of myths, like we call them, they're looking to identify patterns that they actually encounter and use that as a catalyst for discussions with colleagues or whatever. So I'm basically seeing a good response, but it's not a treasure trove of suggestions there. I would like people to be more forward and suggest stuff that we can discuss openly

because we can be wrong. I'm open to be debated on any topic. Well, hopefully listeners will call out to you and suggest some more possible myths after listening to this episode. Do you have any more plans to either do a blog post or do additional streams about this type of content? The blog post thing, I'm thinking about it,

but I'm fairly lazy to do so. But no promises, no promises, but it's on my to-do list. With regards to streaming, i'm up for it so it's up to jason because he has a busy schedule doing all kinds of streaming and recording so i think he spends a lot of time looking at the camera i spend more time looking at the camera than most people but my schedule is less busy than most people, depending on how you look at it. Yeah. So I'm up for it.

We haven't scheduled anything yet, but I'm up for it. Okay. Actually looking forward. Well, before we let you go, Victor, is there anything else you want to plug? Anything coming up soon that you want to tell our listeners about? Or just tell us where we can find you online. You can reach out to me

on Twitter. I'm fairly active on Twitter at surab underscore Victor. As a closing, I'd maybe like to review the stuff we mentioned. the article from Bartek about Visual Studio Visualizers, debug visualizers. I think that's a good starting point.

And I want to encourage people to actually do that. If you're actually using the debugger, and I think the Visual Studio debugger is one of the best in actually presenting information as friendly as possible to interact with it. It's sad that people don't actually leverage the whole power of the visualizers and expose their own types there. So I would really love if more people give that a shot and maybe give feedback to the team to improve the functionality even further. And just to remind people of Clang Power Tools, which is now completely free. And we're actually curious to see more of your suggestions. Where would you like to see this tool

being improved? And if you like the standalone heuristics that we've implemented in the standalone tool for the Clang format detector and the Clang format configuration tool that we've built. So if you have ideas and you want to give that a shot and see if that works for your team, I think it will eliminate a whole class of debates around styles and white space in your code reviews. I think any Clang format style is better than no style. Yeah. We've basically eliminated back in 2016.

When we did that, we eliminated a whole bunch of discussion and problems in diffs. And it's easier to grab for stuff because it's you know where the brace should be you know how the parens is really relative to a function name or it's predictable the format is predictable the diffs are much nicer so i do encourage people to get over their themselves and their particular formatting needs and just agree on a format and just enforce it as a as a as part of the tool chain it changed for every person that i've talked talked with that their team embraced clan format everyone says that it's a life changer so i have never i've never heard an opinion on the naysayer side.

So I think any format is better than no format. And I would like to state, if you whenever get the chance to see Victor in person at some point, the Cling Power Tools sticker is one of the most excellent stickers in the C++ community. Yeah, I always have stickers on me. Yeah. And yeah, if you want to adorn your laptop with some of those yeah but i i think we're we have to wait for in-person conferences

well yeah so you can't pass it on whenever that might happen yeah i i really miss that part that part of actually interacting with people and meeting people and talking with them and hanging out and exchanging ideas, exchanging stickers. So, yeah, soon, soon, I hope. Here's hoping. Okay. Well, Victor, it's been great having you on the show again today. I had a lot of fun. Thanks for having me.

Thanks for joining us. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving

and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash CppCast. 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 was provided by podcastthemes.com.