CppCast - C++Builder

Episode Date: April 16, 2021

Rob and Jason are joined by David Millington from Embarcadero. They first discuss a blog post on Thread Sanitizer and a very unique implementation of unique_ptr. Then they talk to David Millington from Embarcadero about C++ Builder, it's history and the state of the tool today. Including some of its extensions built into their version of Clang. News Eliminating Data Races in Firefox Mathematical constants in C++20 NFT backed implementation of std::unique_ptr Links C++Builder N1384 - PME: Properties, Methods and Events N1600 - C++/CLI Properties N1615 - C++ Properties -- a Library Solution Sponsors PVS-Studio. Write #cppcast in the message field on the download page and get one month license Date Processing Attracts Bugs or 77 Defects in Qt 6 COVID-19 Research and Uninitialized Variables

Episode 295 of CppCast with guest David Millington recorded April 14th, 2021. Sponsor of this episode of CppCast is the PVS Studio team. The team promotes regular usage of static code analysis and the PVS Studio static analysis tool. In this episode, we discuss data races and NFTs. Then we talk to David Millington. David talks to us about a C++ builder, its history, and much more. Welcome to episode 295 of CppCast, the first 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? I'm all right, Rob. How are you doing? Doing okay. Any news to share? No I don't think so not at the moment. Well let's just jump right into it then at the top of every episode I'd like to hear a piece of feedback this week we've got a tweet from Elliot excellent episode fascinating to hear the details of reverse engineering Duke Nukem 2 I'm using the same mechanism as Duke Nukem to log capture and replay input events for the background playthrough on the loading screen of the hobbyist game I'm working on. And I actually kicked off a bit of a conversation between you and Nikolai, right?

Yeah, it was a fun conversation for a few minutes about also how Doom does those things. Because I learned that while I was working on my C++ Doom live stream port thing, which, you know, it's funny because I never really stopped to consider how much I had actually learned during that little experiment. And it was just lots of random little details about the architecture of at least Doom, but not from the, like, how the 3D rendering was done. Like, I didn't care about that at all.

I was looking at, like, the actual, like, structure of the code and how the enemies were defined was done. I didn't care about that at all. I was looking at the actual structure of the code and how the enemies were defined and that kind of thing. Right. Very cool. 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 cbcast.com. And don't forget to leave us a review on iTunes or subscribe on YouTube. Joining us today is David Millington.

David is an Australian developer originally from the island of Tasmania, where in true Aussie style, his family had a small sheep farm. Today he lives in Northern Europe in Estonia. He began programming with a BBC microcomputer and was hired for his first programming job using C++ without ever having used it. In the week before starting work, he borrowed a copy of Strewstrip from a friend of a friend and read it cover to cover. David has a strong interest in user experience and improving what it's like to use software and programming languages. He joined

Embarcadero as the C++ product manager in 2016, and today works as the product manager for both C++ Builder and Whole Tomatoes Visual Assist. David, welcome to the show. Well, thanks very much. It's great to be here. You must be a much faster reader than I am, because it took me like three or four weeks, I think, to read the C++ programming language. It is a massive book. I spent all day for a week just reading it cover to cover.

Wow. And I'm not sure how much of it I actually retained, but at least when I started work, I had a bit more of an idea about C++ than when I was hired. Yeah, right. How did the first programming job go after reading the book cover to cover? Do you feel like that set you up fairly well

for programming in C++? I think so, yeah. I mean, it's a great book. I actually stayed with that company for something like eight years. And it was a great place to work for. You could publish your own book, which would be called Learning C++ in One Week, and it would just be a single chapter.

Anyhow. Actually, I'm kind of curious about your migration or immigration from Australia to Estonia. Was that because you had a job offer in Estonia or what? How did that work out? Not at all, really. I was traveling around about 10 years or so ago. I moved to Europe in general and I was living in Germany for a year and the visa expired and I wanted to move somewhere else in Europe.

And at the time, I mean, as an Australian, I'm not used to the northern climate and five months of winter and deep snow and that kind of thing. So I thought, well, you know, head off to Estonia, which I knew nothing about. Took my suitcase and boarded a plane and found a place to live and realized it's actually a fantastic country. I love it here. That's awesome. It's a fun adventure for sure. Yeah, definitely. It's a really high-tech country as well. I think that's one of the reasons I like it. It's plenty of startups here and everyone has a digital ID card and you can sign all your documents electronically, vote online, that kind of thing.

It's a very advanced country. That's pretty cool. And I feel like I may be confusing something now, but isn't Estonia one of the countries that has something like a digital visa or something like that to try to encourage more business and commerce coming their way too as well. Yeah, that's right. It has a e-residency program. So I'm actually not really sure of the full details, but I know it lets you start a company here. I mean, you're starting a business, you're registering a company

and stuff is normally fairly complex wherever you are. But I know this allows anyone to do that in Estonia, so you can start an Estonian company, you know, get bank accounts, that kind of thing. And, yeah, it makes it fairly painless. Interesting. Yeah. All right, David. Well, we got a couple news articles to discuss.

Feel free to comment on any of these, and then we'll start talking more about C++ Builder, okay? Sure. All right. So this first one is a post from the Mozilla Hacks blog and it's Eliminating Data Races in Firefox, a Technical Report. And this is all about their use of Thread Sanitizer, which I'll be honest, I was not too familiar with Thread Sanitizer before, but it sounds like a pretty powerful tool as i was

reading this it just made me think of how you know microsoft has brought a sand to visual studio and i i kind of hope that they're working on bringing t-san as well it sounds pretty awesome i have to i was not familiar with the thread analyzer either so uh i learned most of what i know about it by reading the article yeah um i I was particularly struck, though. One thing jumped out about, I mean, I found many sort of common threading issues, but one thing that really jumped out was where code that had not been intended to be called from,

I think, a non-main thread has been called from multiple threads. That's a difficult situation to discover. Yeah, and they mentioned that one about how they think it may have been uh in this example it was uh writing to the preference file that they use and they think it may have been the cause of some mysterious bugs where firefox users were reporting that their you know preferences were getting lost and or corrupted and they could never reproduce it so i think it probably was

caused by this uh bug that thread sanitizer was able to find it'd be very satisfying to nail down a bug like that yeah i actually have used thread sanitizer in the past and when when it gives you this kind of report it's almost like magic like to the point that you're like well if you just identify that there should be a mutex lock there, why don't you just, you know, tell clean tidy and insert it for me? Because that would save an awful lot of time here. Yeah, the report generated here does look pretty wonderful, how it just points right to the two blocks of code that are both trying to work with the same piece of data. Sorry, go ahead.

I don't know if anything like that would be planned. I mean, integrating some of these sanit into clang tidy seems a fantastic idea i don't know i've never heard anyone mention it before i don't know what the practicality is i feel like at the very least it should be able to generate a diff for you a suggested diff that you could then just apply and see if that fixed it that could be interesting yeah yeah because i think address address sanitizer in some rare cases might also be able to give you similarly like you needed to check this variable uh for null before you dereferenced it or something like that but that could fundamentally change the behavior of the code too in some places if it got

it wrong i don't know i thought it was interesting that they're like going on and on well from my perspective on and on about like oh well there are some things that was like you know a little bit of noise things that weren't very serious and we had to sort through all of these errors and then you finally get down to the error count that they had to sort through and it was 64 i'm like you know all things considered that's not that many. Yeah. And they classified some of them as being somewhat benign, but I believe they said they kind of, you know, are trying to get rid of all of them anyway,

even if the ones that they feel could be benign, which sounds like a good idea, especially if it is only 64 errors. Yeah. I noticed in the article as well, it said that every message it gave was always correct yeah it's not always the case for for these kind of tools yeah they said the tool itself i think guarantees no false positives which is uh pretty impressive my understanding of how both thread sanitizer and the equivalent behavior for valgrind's hellgrind tool work is that they take your multi-threaded application

and actually single step in a single threaded environment, like manually task switching between the threads so that they can then say, okay, well, we just intentionally interrupted this thread at an inopportune time. Is there another thread trying to access the same data? And that's how they can detect these things and be very accurate about them. It's possible I have a too high-level understanding of that. Very cool. All right.

Next thing we have is a short blog post on Meaning C++ blog. And this is mathematical constants in C++20, which I don't believe we've talked at all about when going over new features being added to C++20 or that have been added in C++20. But this one is mathematical constants that you probably have some macros defined for in your code,

like pi and a couple others here as well definitely some fun ones I've never worked on code where I've needed these honestly I've needed pi like once in my whole career I feel like I'm always using pi but yeah some of these I'm not familiar with like phi the golden ratio I'm not sure how that would be used in in code right I'm not sure about that one be used in code. Right. I'm not sure about that one either. Yeah. I have to admit that adding constants like this seems a very, I mean, a very nice small addition.

Oh, yeah. Yeah, definitely. Just removes that macro that you have all over your code. Use this instead. Makes sense. All right. instead makes sense all right and then the last thing we have uh is an nft backed implementation of stood unique pointer and i don't think we've talked about nfts at all on the show jason we've certainly i think done an episode or two about blockchain which relate to nfts but um yeah this is pretty wild code you want to tell us more about it

i don't really know anything about like i know just barely enough to understand what's not even to understand what's happening here i i know i understand just barely enough to get the joke i think yeah yeah so nft was a non-fungible token non-fungible token. Non-fungible token. And I believe, you know, I first heard about them a few weeks ago. They became popular. People are like buying NFTs for like popular digital art. And if you own the NFT, like that's saying kind of you own the art, even though anyone can still go and view it because it's just on the web. Anyone can look at it. But by having this NFT, you have some ownership of it. it's just on the web anyone can look at it but by having this

nft you have some ownership of it i don't understand the point no so you can track in a secure blockchain way full ownership of your unique pointers right and the person actually went out and implemented all of this yeah you can create objects on the blockchain and i would imagine it would be very slow to run this code if you're using lots of unique pointers that have nfts backing them i don't you know i don't think they put any stats into this no there is a benchmark oh is there okay yeah yeah so uh it says the performance uh overhead is negligible. Oh, okay. Creating a unique pointer takes.005 seconds, and creating an NFT pointer takes three minutes. Oh, that's not bad at all.

Oh, that's great. I love the tone of that readme. Yeah. There are jokes like that scattered through the entire thing. To anyone watching this, I do recommend you read it through. Yeah, the best thing is he has a bunch of bullet points about why he's gone ahead and done this.

And then after the last bullet point it says, for more information, please read our white paper. And if you click on that link, it's a literal just white page. Completely blank PDF. Fantastic. I should do PDF. It's fantastic. I should do that.

That's great. And here's another bullet point that the Reddit readers pointed out. As we all know, adding blockchain to a problem automatically makes it simple, transparent, and cryptographically secure. So if you need to solve your memory problems, here you go. Yeah. All right. So, David, let's start talking about C++ Builder. And maybe we could start off with you giving us a bit of a history of the tool, because it's not something I grew up using.

But I feel like a lot of our listeners probably have some experience using an older version of C++ Builder. So maybe tell us about that and how it relates to today's C++ Builder. Sure. Well, it's great to know that you used to use it, actually. I didn't, but I think Jason was nodding his head. I was nodding my head because I know lots of people who have. I've used, I think, C++ Builder very briefly a while ago, but I know lots of people. If it comes up on Twitter, lots of people have experience with it. Well, yeah, it really was all begins with Borland,

which of course was a famous name back in the day in the 80s and 90s. And they had Turbo C++ and so forth, and they created C++ Builder to target the, I mean, it was then Windows, but to help people build UB applications. And I think still today that's our main focus, trying to help people build your normal sort of desktop or mobile or so forth, app with a user interface. I mention that because, of course, C++ is used often for many other things, you know, finance or data processing

or scientific analysis or something that isn't necessarily directly hooked up to your normal window. But that was the focus then, and it's still the focus now. And, yeah, as you mentioned, it was really popular, I think, in the early 2000s. And the product's still widely used, I think, in the early 2000s. And the product's still widely used, I think, but not really so well-known anymore. Okay.

And it's gone through a couple of different companies, is that right? Yeah. It went from Borland to Embarcadero. Yeah. So Borland, I don't know, changed focus and sold off its developer tools division. That became a company called CodeGear, and that was bought by Embarcadero.

Okay. And all this happened, I think, in the late 2000s, well before I joined the company, so I'm trying to remember the history here. And then in 2015, Embarcadero was bought by Idira. Now Idira is a very large, actually, software company based in Texas, and it owns a number of developer

tools companies. It owns Whole Tomato as well, which make Visual Assist, which I also work with. You know, Censure, Travis CI, a whole bunch of different sort of tools like this. Oh, okay. And, yeah, basically when they bought Embarcadero, Embarcadero has sort of two main tools.

So there's Delphi as well, which, again, I guess many listeners are familiar with, especially from the early 2000s when it was very popular. That's a genesis from Turbo Pascal onward to Delphi, right? Very much, yeah. So Delphi effectively added object orientation to Turbo Pascal and built a beautiful new library called the VCL as well, which wraps the native Windows WinAPI layer. And actually, that library is usable from within C++ Builder as well, because our dialect of C++ can interop with the Delphi language.

You can even write a C++ class that inherits from a Delphi class. And yeah, so at the time when Idea acquired it, Delphi had a product manager and so forth, but they were looking for someone for C++ Builder. And yeah, that's when I joined about five years ago. Okay. I feel like it's worth maybe just taking a second here to, so you said the Turbo products, a lot of people are familiar with, and certainly like anyone who was programming in the 90s

for sure knew Turbo C++ there's no question and Turbo Pascal and so these tools that's just Turbo C++ was being developed, it just kept being developed and now you have what you have today. Is that fair

to say? Is it the same history lineage well not quite because um the ball and in the ball and days the c++ compiler the one we call internally we call the classic compiler now the ball and c++ compiler um came from that that lineage uh but around 2010 um you know when c++11 was around the corner, the development team was looking at some of the stuff that was coming in C++11 and realized, especially with the changes in template handling and so forth, that the old C++ compiler code base was really not viable to take forward to modern C++.

And so we switched to using Clang. So what we use today, we still provide the old compiler. Not very many people use it, but some people still have projects based on it. And of course, it's got a history. So is that like only C++ 03 supporting compiler? That's right. And a few things from C++ 11 that could be implemented,

but generally just regarded as C++ 03. But what we did then instead was to take Clang and to add our language extensions and so forth to Clang. So when you install C++ Builder today and you create a new app and compile, you're actually using a slightly modified version of Clang instead of the lineage from the old-born tools. So you have to maintain your own patch set on Clang? We do, yes. It's quite an extensive patch set as well.

I mean, we add quite a few language extensions. So the patch is mostly in the front end, not in code generation, but yeah, there's quite a significant amount of work there. So, I mean, I keep bringing back that interview with Patricia last time she was on, Rob, but she was working on building her own Chromium-based browser, which has its own patch set as well. And apparently these large projects, particularly those that have influence from our friends at Google, tend to not be very stable ABI kind of codebases, and the patch sets are difficult moving targets.

I'm just kind of curious, like, how much effort does it take to maintain your patch set so that it can still be applied to the next version of clang well actually it takes quite a bit um there's an interesting question because we've been discussing internally about changing our approach to how we how we maintain this um so uh what we tend to do is we tend to to pick a version of clang and stay on it for for you know for a couple of years before moving forward to another version, which can be unfortunate because we have a couple of years' worth of Clang changes that we don't make available to customers. But it does mean we can sit with a single version and ensure it's rock solid. But, you know, there's quite a wide variety of changes.

And what I've been told by the developer team is that Clang can often, and I wish I could speak with more authority about this because I'm not a compiler engineer. So, you know, this is kind of secondhand, I'm afraid. But what I'm told is that often Clang does make fairly major internal changes that can make porting code forward quite difficult. And that tends to be what we do.

I mean, we merge our changes in through Git and track the changes forward. But every so often something has changed that requires quite a large amount of work. So we're thinking internally about our next sort of stable version of Clang that we'll pick for the next couple of years, and whether we should take that approach of merging forward or take a different approach which might be, you know, rather than trying to merge the patches, try to write some of the features anew. One of the reasons for that is that, you know, as Clang changes, the right way, you know, the best way to

write something changes as well. And that would let us take advantage of, you know, doing something new, doing it the, you know know in the past it was the right way to do it one way but you know now it might be better to implement a different way in the uh in the past i've tried to take where other people have created like a z80 back end or 6502 back end or something for clang and try to say okay well can I apply this to the current clang develop for a branch or whatever? And if that patch set is more than like a year old, it seems like it's virtually impossible. And that's just a tiny back end. So I can only imagine what you all have to deal with.

Yeah, it does get quite complicated. I think a year there is probably a good estimate of when the churn becomes very large. And we tend to go over a couple of years' worth of versions as well. So it is doable. It just takes a reasonable amount of work. I mean, this is several months' worth of work to do that. Right. So do you want to talk more about the C++ extensions

you're putting into the language to make all this necessary? What types of extensions are there? Sure. Well, there are extensions for a couple of reasons. One of them is, as I mentioned, we make Delphi as well. And Delphi and Pascal and Object Pascal is quite a different language to C++, especially in the past 10 years or so.

I think they've sort of diverged. You're in the, I'm not really sure what to call it, I know the mindset of language design has changed quite a bit. And so some of our extensions assist with the interrupt there. So there are Delphi language features that we want to make available to C++ developers. The other reason for some of the extensions is simply that it allows a different approach

to, I guess, library development or consuming libraries than is normally possible in C++. So an example here would be to do with our UE libraries. This kind of crosses over both because the frameworks that we make available are focusing on user interface here, but we have many other things in the RTL, sort of a bit like Qt.

I mean, Qt has a very large RTL that they provide with their own string implementation and so forth. And we do the same with our own strings and JSON and REST and so forth. All of those are actually written in Delphi. The Delphi compiler emits a C++ header, and you include that C++ header and then just link against the Delphi object files. So from the point of view of a C++ compiler,

it has no idea that it's speaking to anything that's not C++. It has a perfectly valid C++ header, and the linker is perfectly happy, and it all works rather well. Interesting. But an example I think, sorry, I sort of went off track there. No, that's fine. Explaining that. Would be adding properties.

So properties are something that have never been in C++. But if you're developing something like a UE library, then they're a very, I don't know, useful idiom, you know, to set and get state and sometimes to cause, you know, usually setting, but sometimes getting to have an action occur as well. You might have a, I don't know, a property like caption, for example, that represents the, you know, the window title. And so property allows field-like semantics to that.

So you can just access it like a field. It looks like a field in code. You have your pointer to the window arrow caption, and you can assign a string to it or read a string to it. But of course, when you set the window caption, you actually want something to happen under the hood. And so the assignment there isn't just a field assignment, but it actually invokes a method. And that looks after the actual work of changing the window text. Interesting.

Sponsor of this episode is the PVS Studio team. The team develops the PVS Studio Static Code Interesting. through the boring parts of code. Never gets tired of looking for typos. The analyzer makes code reviews more productive by freeing up your team's resources. Now you have time to focus on what's important, algorithms and high-level errors. Check out the team's recent article, Date Processing Attracts Bugs or 77 Defects in Qt 6 to see what the analyzer can do. The link is in the podcast description.

We've also added a link there to a funny blog post, COVID-19 Research and uninitialized variable, though you'll have to decide by yourself whether it's funny or sad. Remember that you can extend the PVS Studio trial period from one week to one month. Just use the CppCast hashtag when you're requesting your license.

So when working on some of these extensions, have you ever considered trying to bring them back into standard C++? I have a feeling that properties has probably at least been thought about by the standard committee, and I know there's the whole metaclasses proposal. But have you ever considered kind of bringing that work back into standard C++? We have. It's interesting you mentioned metaclasses because we have those as well. A very light implementation, but we use metaclasses to allow virtual construction because in C++ a

constructor is not virtual. Right. And actually, before I answer the question, I think it's worth mentioning one other extension as well, which is misnamed today, but it's called a closure, which is a way of capturing an object-oriented method pointer. So the syntax is very C-like. It's like a C method pointer, but it captures the object reference that the method is going to be called on as well. As I said, closure is kind of misnamed because it doesn't really capture more than that,

but that's history. And those are very useful for events. And again, we get back to UE programming because something happens. You click on a button and you want something to occur. And this idea of capturing an object oriented method pointer allows you to delegate the behavior. So your button will store a pointer to the method that you want called when your button is clicked. And that can be

anywhere, it doesn't have to be in any specific button class or window class. And so this set of things, the property method event model was actually proposed back in about 2002, I think. And I went and looked up the papers. So if anyone's interested, then the pre-Santa Cruz meeting in 2002, we added our proposed N1384, just in case anyone wants to look that up. 2002, wow, okay. through tabs here in 2004 there was a prop a proposal for C++ CLI by David van der Voorde and apologies if I mispronounce that I think that's pretty close yeah great and you're of course Microsoft was working on you know C++ CLI back then as well and they right they they i i think um i don't want to

speak on their behalf but i i think they wanted properties for much the same reason um yeah because it allows a different sort of programming model um and uh that one is in 1600 and uh then there was another paper uh in 1615 um which actually was was quite critical of the idea of properties, that they weren't very C++-ish. And this is the last that I can find in the Standards Committee papers. Now, this is still 2004, so it is long, long before I ever got involved, and I can't speak with authority to what happened. But it looks to me as though this particular last paper

was influential and sort of killed the idea of adding properties to C++. It happens from time to time. Yeah, it does. I'm curious what killed it. I need to go and find and read that paper. If we can try to get links to all those, yeah. Yeah, it does have some good points.

I think the main point of the paper was that properties and events are very useful for a specific type of programming, specifically UE libraries, but they can be misused. And the paper seems to be concerned about that misuse. One reason there is that the action of setting what appears to be a field, I mean, you address it in code like a field has side effects because it could invoke a method. And you can certainly see how that could lead to badly architected applications

or unexpected behavior or something like that. So that's certainly a valid concern. For me, I think we tend to think that the benefits outweigh the risks there because it does allow very elegant code. But I think like everything, you need to use it in the right place in the right way. Right. I'm kind of curious because, I mean, you know,

this event driven GUI development thing, it's, it's QT has their signals and slots mechanism, which sounds pretty similar. Uh, but I, whenever I hear a conversation about event driven asynchronous behavior, it seems like co-routines keep coming up. Um, even not necessarily even C++20 coroutines, but I was just curious with all these language extensions you were talking about, if you had anything like a coroutine from before or not. We don't, no.

When I say events, I think perhaps it's a smaller definition than is often sort of meant by the term today. So it's not asynchronous. When an event is called, it happens in the UE thread. Okay. But I think coroutines would potentially be quite useful in some ways, but it's definitely not something that we've ever looked at.

So this is like a button is clicked and you want to notify these other three widgets that a button was clicked kind of, or controls or whatever. Is that the kind of event you're talking about okay yeah yeah pretty much and an event here really means um you're calling a method uh you know when something happens and the win is the event okay um you know call a call a method via this uh you know this method pointer okay uh so when we first started off talking about C++ Builder, you mentioned that it's kind of based on Delphi and mostly used for UI development.

Is it specifically for UI development on Windows or is it a cross-platform targeting application? Our main focus is on Windows. So at the moment, you can build apps for iOS as well. And for a while we supported Android as well. We're considering adding that back, but there wasn't actually a great amount of demand there. I think we

may in future go back to Android and Mac OS and even Linux as well. But yeah, the main sort of interest is for Windows development. Okay. And since you're using your modified version of the Client Compiler, are you on a pretty new version of C++? Are you targeting like C++ 14, 17, 20? C++ 17 at the moment. And yeah, I mentioned earlier that we sort of tend to pick a version of Clang

and regard that as our sort of stable release for a while. And obviously with C++ 20 out, we want to upgrade. Right. So yeah, we're considering when and how to do that at the moment. But, yeah, currently it's C++ 17. I feel like if your next goal is C++ 20, based on current compiler conformance to the standard, you should wait a little while.

Before investing the effort that is, because you know, the compiler is going to be a moving target, but anyhow, right. I'm curious to go back. If you don't mind to this Delphi C plus plus integration. So you said your Delphi compiler just emits a C plus plus header file that

can be consumed by clang. So first question is, does that go both ways? Can I consume a C++ header from Delphi and use an object from C++? Not really, no. You definitely can't consume a C++ header. And I think the main reason for that is that there's a lot of constructs in C++ that there is no equivalent for in Delphi. Whereas I think 98% of Delphi has constructs that have equivalents in C++.

So that makes it a lot easier to go in that direction. But there are ways to achieve it. For example, often when Delphi developers want to make use of C++ they'll write an interface in Delphi. Then that interface, the unit with the interface in it is compiled and becomes a C++ header

with C++ doesn't have interfaces per se, but you can have a pure virtual and so forth. Right. And then write a C++ class that inherits from that and does whatever you want in C++. But the Delphi code will talk to a Delphi interface and be completely unaware that the implementation of that interface is actually in C++. Okay. So does this imply then that your Delphi compiler uses the same

object layout and calling conventions from an ABI perspective as the C++ compiler? It does, yes. And actually some of this is the work that we need to do as well. So in terms of modifications to Clang.

Oh, interesting. Okay. So I focus mostly on extensions because I think extensions are quite interesting to modify the C++ language. Well, not modify, it's a superset. But, yeah, I mean, Delphi has, on Win32, for example, it has a different calling convention, a register calling convention, a register calling convention that other compilers don't implement, for example.

And so we add that to Clang. And a few other interesting things as well. I mean, Delphi is a different approach to language design, I think. So, for example, some of its types you could refer to as managed. So a string, for example, is reference counted and copy on write. And things like this, like string and some other sort of inbuilt high level primitive data types, like we have one called currency or a date time one and a few other things like that we actually have special abi support for as well oh built into your front end yes interesting okay i'm kind of curious what that uh what that looks like why do you need to build that into the

c++ front end instead of being able to consume the header files emitted from? Well, the header file will simply say that there's a string parameter, for example. But these types, I mean, the majority of things in Delphi are just classes or structs or so forth. And they just have a header version emitted. But some of these things are sort of inbuilt types to the Delphi compiler, and I think string's a really good example there. So in Delphi, string is a Unicode string.

It's wide character string. And it's, as I mentioned, sort of reference counted and copy on write. And there's no sort of header translation of that because it's an inbuilt primitive in the compiler. Okay. Now, we actually write a C++ class that implements exactly the same thing and is layout compatible. Okay.

And so when you include the headers for our RTL, you'll include a header for that string class. And so we have a C++ implementation, basically, that is actually what's used when you use this Delphi type in C++. But because it's layout compatible in memory and so forth, Delphi will consume a string that was created in C++ unaware that it wasn't the Delphi compiler primitive version.

You're like, here's some bytes. Trust me. Exactly, yeah. And going along with this is that these sort of inbuilt compiler primitive types, it varies depending on the type, but some of them have some special semantics around how they're passed into a method. I see. So, yeah, that's the kind of thing that we need to add. So currency, the one that you brought up, it's fair to say that's actually a primitive in Delphi. Yes, yes, that's right.

Okay, I missed that the first go around. That's very interesting. Well, I may not be explaining things very well, and my apologies for that. That's fine. I need to drink more caffeine. And I haven't had any yet today. So ABI stability in C++ is something that we've brought up a lot on this show over the last few months. And it sounds like you all have to be concerned not just with ABI stability in your own code,

because it's being shared between the things, but you also have like a cross-language ABI stability. Although I guess on the other hand, if you needed to ever change the layout of currency, you control the whole ecosystem anyhow. So you can just be like, yeah, yeah, we changed it. It's fine. And change it on both sides. Yeah. Yeah. That's, that's right. And we, we, we tend not to change the ABI very often. In fact, we've only made one change in the whole time as I've been product manager. Wow. And in one sense, as you say, yes, I mean, we control everything.

So here we have our C++ compiler engineers and Dolphy compiler engineers, and obviously we work together and make the change. But it's never quite as simple as that because an ABI is a complicated thing. When you're on a project and you're you know building your application are you typically building everything from source or are uh library like components being passed around a lot that you know breaking abi would be a huge

problem well actually there's a couple of answers to that. Okay. On the Delphi side, the compiler engineers keep ABI compatibility between major releases. Now, that's the ABI not in terms of how a parameter is passed to a method, calling commission or so forth, but the ABI in terms of the layout of a data structure and something like that. And so the flexibility we have there is that we can change the internals of class that affect layout and other things like that, add methods, remove methods, so forth,

every major release. So that's one form of ABI. And so that means that every add methods, remove methods, so forth, every major release. So that's one form of ABI. And so that means that every major release, of course, you need to recompile your source fully between minor releases. You don't have to. Yeah. On the C++ side, we're a bit more flexible. We actually give ourselves the flexibility

to make changes even between minor releases. Oh, okay. And I think the reason for that is that we've found that our C++ developers are much more happy just to rebuild when they install a minor update than the Dolphy developers are, which is great because it gives us a lot more flexibility. You can constantly sort of iterate and improve much, much faster there. That sounds to be the exact opposite of experience of what the Standards Committee has been discussing, since they have voted to not break ABI compatibility within the C++20 timeframe.

I think C++23 might still be open for discussion. I did read that, yeah, but i'm not quite certain of the reason do you know um you know why um my understanding is that the effectively the reason is they don't want to fracture the language kind of because if they break abi compatibility then it might get people stuck on older compilers because they're relying on older binary blobs, DLLs, whatever of some sort that they can't rebuild. That is my understanding. I should probably go back and look at some notes because I've been thinking about this a lot the last couple of days. That makes a lot of sense. And it is interesting that it's kind of the opposite to our experience,

as you mentioned. Yeah. I think it comes down a lot to, I don't know, say if someone has a DLL that controls some proprietary piece of hardware and they don't have access to the source code to that, and perhaps the company's even gone out of business that provided to them in the first place, then now if they upgrade their C++ compiler or upgrade their standard library implementation,

they can no longer control their $100,000 piece of equipment or something like that. But from my perspective as an outsider, I feel like if you're relying on a piece of software that you don't have the source code to and it's decades old anyhow, you're kind of already up the creek. Yeah, you're probably not the type who's worried about upgrading to the new compiler anyway.

It's possible I'm exaggerating or taking too high a level of the... But does that sound about right from what we've heard on the show, Rob? I think so. Okay. It seems to come up about every third episode or so for some reason or another. So, David, we've talked a lot about the internals of C++ Builder. Do you want to tell us a little bit more about the types of applications that developers are typically building with it

and what types of tools C++ Builder is giving developers to make that easier? Sure. Well, as I mentioned, I think one of the main reasons developers use C++ Builder is because of the UE frameworks. So we have our main Windows UE framework called the VCL and also a cross-platform one called FireMonkey. And I think we make hooking up UEs to code easy. It's not always something that has been easy in C++.

Qt makes it easy as well, I think. And they have the same problems that we do in terms of C++. You're not really quite supporting the models that are needed for this kind of thing. And they obviously take a different approach to the solution. But yeah, to sort of paint with a broad brush

the average C++ builder app, it would be a Windows UE application. But beyond that, it's hugely varied. I mean, software in, I don't know, science, there are many sort of scientific apps and analysis apps written in C++ builder. There's software for industrial automation. There's even software that works in power plants. There's, you know, desktop software that people sort of sell, you know, the kind of software that you run on Windows that you might buy yourself.

You know, it's sort of too broad to even really be able to pin down. But, yeah, I was trying to think now, and I'm on the spot, and I've forgotten, but there are definitely apps that you've probably used on Windows that are written in C++ Builder. Okay. So does it, you have implemented your own GUI controls? You take that approach, right? Yes.

So just out of curiosity, because it's been a while since I, you know, I, you say that there's lots of apps and I believe you. Um, I'm just kind of curious if you, as the, one of the team developers, if you can pull up an app and be like, Oh yeah, this was definitely a C++ builder app because I know the feel that our, our widgets have, our components have. Sometimes on Windows, it's much harder because when I say we write our own controls, they wrap the Windows APIs. Oh, okay. So it feels like a Windows app.

All right, cool. But of course, you can write your own controls as well. Right. And there are some quite common controls in our ecosystem that you sort of recognize. You pull up an app and you think, okay, that particular tree view is probably a virtual tree view, which is the name of one of the very popular third-party components

or something like that. I think on mobile it's easier because for the cross-platform framework, we do write our own widgets from scratch. And we try very hard to mimic the application look and feel. And actually for some controls, like on iOS, for example, you can choose whether a text import is our version or the native version. Of course, if someone chooses to have the native version,

then you can't tell. But yeah, we do try to get very close to the native look and feel as well. Cool. So even that can be hard. And I think there's one reason for that is that we value helping developers create interfaces that feel right on whatever platform they're on. And a good part of being right is being, or feeling right to a user of an app is sort of being indistinguishable in behavior

from every other app on the platform, which if we meet that target, then we've done a good job. But it makes it hard to answer your question about being able to tell that an app is built with C++ build. I think that answered my question perfectly because I was curious, like WXWidgets uses as much as possible the native components underneath, which it sounds like that's similar to what you're doing.

And it can be very difficult to tell the WX app sometimes. And Qt depends on how they've skinned it or whatever. And yeah, so yeah, you did answer my question. So that's pretty cool. Sounds like it has a nice native feel. That's certainly what we aim for, yeah. Okay. If listeners are interested in trying out C++ Builder,

is there a free demo or is it available for open source or anything like that? Yeah, there is. It's not open source. It's a commercial. I meant some products might be available for free if you're an open source developer or something like that. We have a community edition

that's quite similar to the Visual Studio community. But that's actually running about one release behind at the moment. We plan to update that soon. So actually right now, I would suggest not checking out the community one because it's not really up to date with what we're offering at the moment. There's a trial version, and it currently is a 30-day trial, but I think we're planning to extend that to a 90-day trial very soon. So possibly by the time this is live and broadcast,

there'll be a 90-day trial. And that's just Embarcadero.com and the products menu and C++ is listed there and there's a free download there. Very cool. Well, is there anything else you want to go over before we let you go, David? Well, I think I could talk about some of the internals and the things we do for hours. And I hope I haven't sort of talked too much or kind of waffled off topic a little. No, not at all. It was interesting. Yeah. Well, I'm glad you found it interesting.

Yeah, I do think there's probably not much else to cover today. I hope that people would find C++ Builder interesting. I mean, if you used it in the past, you know, to check it out again. And, you know, Idea is quite, you know, committed to its C++ tools. I mean, as I mentioned, C++ Builder is not the only C++ tool that it owns. You know, there's Visual Assist, for example. And so, you know, it's not well known, but it's there and steadily getting updates and work done on. And who knows, you know, maybe I can come back in a year and tell you about some more. Sure. At some point after C++ 20 support has been finalized or

something. Sure. All right. Well, David, it's been great to have you on the show today. Well, yeah, I really enjoyed it, and I really appreciate the invitation. So thank you very much. Thanks for coming on. 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