CppCast - Maintaining QtCore

Episode Date: February 27, 2020

Rob and Jason are joined by Thiago Macieira from Intel. They first talk about Visual Studio's Qt support, and articles from Bjarne Stroustrup and Herb Sutter. They then talk about Thiago's history with Qt, including his former role as Qt Release Manager and his contributions to QtCore, QtNetwork and more. News Jason's C++ Training Courses in Stuttgart Fuchsia Programming Language Policy Qt to support Visual Studio Linux projects Bjarne Stroustrup on C++20's significance Move, simply Links New Features in Qt 5.15 Clear Linux Project Sponsors Backtrace Software Crash Management for Embedded Devices and IOT Projects Announcing Visual Studio Extension - Integrated Crash Reporting in 5 Minutes

Episode 236 of CppCast with guest Thiago Maciera recorded February 26, 2020. and gaming platforms. Check out their new Visual Studio extension for C++ and claim your free trial at backtrace.io slash cppcast. In this episode, we discuss Bjarne's thoughts on C++20. Then we talk to Thiago Maciera from Intel. Thiago talks to us about his contributions to Qt and more. Welcome to episode 236 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? I'm doing good. Do you have any news you want to share? No news. Just maybe a reminder that I do still have that class coming up in Stuttgart at the end

of September. And I think we could put a link to that in the show notes if people are interested in checking it out. Okay. Yeah, we can definitely do that. Do you by any chance want to plug your other YouTube channel, Jason? I don't know. Okay, so now that you've gone and said this,

I did an experiment a couple of times of strapping a camera to the back of my dog and just doing long form jogs with the dog. The idea being that you would hear the environmental sounds, the cars driving past the other joggers and the other dogs that we go past and that it would be like a relaxing kind of, uh, uh, video. Um, it didn't work out quite as good as I wanted it to. I'd probably need to invest about $400 more in equipment. Not sure if you're going to go down that road though. Okay. Yeah, because I need a really good gimbal and a better camera because there's just too much shaking.

I mean, if you imagine strapping a fulcrum onto the back of a dog's back, basically, or lever arm, and how much back and forth there's going to be doing that. Right. Yeah. Okay. Well, it's a cool idea. Okay. Well, the top three pieces of feedback.

We got this email from Kashish saying, Hi, Jason and Rob. I'm a big fan of your podcast and a C++ enthusiast. Can you discuss the role of C++ in Fuchsia OS? And he sent a link along. And I'll be honest, I may have heard of Fuchsia when it was first announced, but I really know very little about it. But it's a mobile operating system being worked on by Google separate from Android. Have you heard of this at

all, Jason? I have heard of it. I think, um, I mean, the main way that I'm familiar with it is I have to disable the fuchsia text and cling tidy because they just warn on things that I do not want it to warn on. They're very limited set of C plus plus that they can use. Oh, interesting. I don't know why. Okay. Well, it looks like if you're making a Fuchsia app, you have a couple options, including C and C++ and also Dart, Rust, and Go. I honestly don't know how widespread

Fuchsia app development is, but maybe we could get someone on from the Fuchsia team sometime to talk more about it. Sure. Yeah. 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.cpgas.com. And don't forget to leave us a review on iTunes or subscribe on YouTube.

Joining us today is Tiago Maciara. Tiago holds a double degree in engineering and MBA. He's been involved in several open source projects for nearly 20 years is an experienced C++ developer he's been involved with Qt and KDE since 2000 and was the author of quite a few classes in Qt Core, Qt Network

and the entire Qt DBoss module he's been the maintainer of Qt Core since 2012 he currently works for Intel System Software Products Linux team where he's a software architect for the Clear Linux project for the Intel architecture, with responsibilities including expanding Clear Linux to new segment end uses.

Tiago, welcome to the show. Hello, thank you for welcoming me. Certainly. Can you tell us what the Clear Linux project is? I don't believe I've heard of that. Certainly. So Clear Linux is a Linux distribution. We started here at Intel about

six years ago. It has roots in just trying to do things differently in Linux distributions to have more performance and better support for Intel features. One of the first things we did way back then was to try and make the boot really, really quickly. It started in older projects where by the time Linux distributions booted in about a minute from power on to a graphical desktop, we did a lot of work to make things boot quickly. And this is one of the things that led into SystemD. Now, we're not claiming responsibility for SystemD today. It's just that once we started doing this, the same engineers began realizing there were a number of other things that could be done better on Linux.

So we put together a Linux distribution that was supposed to be telling others, here's how we think you should be doing things. No compromise for older hardware. And by older, I mean anything that today is older than 10 years old. We still have quite a bit of support. And just showing what you can do with performance. So we apply some very small kernel patches to change some defaults. Nothing really big. We do not backport features.

We do not do anything like that. We just stay on the main line besides applying configuration changes. We build software with more optimized flags. We have AVX2 and AVX512 optimized versions of the software running side by side, which at runtime, the system decides which one to load, so get the best performance on your CPUs. If you search for ONNX, you can find independent benchmarks between Clear Linux and other Linux distributions.

We often come on top on something like 40% to 60% of the benchmarks, if not more. So we're quite proud of what we've achieved. And this got the attention of our management. And they said, well, can you also help us push some more Intel features? Can you help us show how Intel features would benefit our customers? So this is my work today, my day job, let's put it this way, which is to talk to the other teams inside Intel. They're working on new hardware features, either CPU, GPU, some other peripheral, and have them integrate their software with us. We can test it.

The entire company has access to it. And we also make it part of the Linux distribution. So our customers and our users are getting it. And then we have a separate team close to me here in the office as well, who goes to the other distribution and say, hey, your customers are going to want this feature, and here's how Kali Linux packaged it. So please take a look at our packaging and adapt to yours.

So is it that, since it's a full Linux distribution, is it based on any other existing distribution? Like, how do I, you know, install Firefox or whatever on it? We can install, we have support for AppStart. And we do have a number of other flat pack and other third-party components. We have a great wealth of software. We just are unable to redistribute some of the proprietary things.

And that includes, unfortunately, both Chrome and Firefox. Okay. Because of the trademarks, and Chrome itself can only be distributed by Google, right? So we can have Chromium, but people want Chrome. So we decided, well, let's not waste our time building Chromium, if you can just download Chrome. And you can download Chrome and Firefox. So we have all of the documentation for you to do it. But besides those, most of the software in the desktops, especially, they're already present. It's not

based on an existing distribution. So you're not going to be able to download .deb from Ubuntu or Debian because we don't use deb. And the same thing, you cannot download an RPM from Fedora, for example. But we're very quick in terms of

responding to requests. So if you post on our GitHub issues page, hey, can you package this? It usually takes about two days or three days, and the software is ready for you to use. That's even if you don't want to compile by yourself. Right. So just out of curiosity, do you then also publish what compiler flags you use if someone else is like saying, hey, I want to know what the best practices are according to Intel? Yes, we do that. We do all of that, right? So I don't think there's a white paper where we discuss all of these things, but you can always download the information from the source packages, and it's all on GitHub. So all of the compiler flags are present, and all of the patches are present. There's nothing secret about this. We actually

want other distributions to adopt it. So we want to make it easy for people to see, here's how ClearLinux did it. Please adopt these flags. It's not very complex, right? I can look at my system right now and tell you which ones we built with. We sometimes push from O2 to O3, right?

So optimization flags. But besides that, the thing is that O3 enables the tree vectorizer. So it enables the auto vectorizer, if you know what that is, right? Yeah. And it makes the code grow bigger. So we don't do it for everything. But for a few packages where we want best performance, we do that. Let me just open here on my system generic package.

I'll say make, right? And let's see what flags we build make with. It's not showing here on this file. It will take a minute to give me the results. Sure. But, yeah, another thing we do, as I said, is that we try to build multiple times. So we build maybe with a baseline, which is Westmere, the first Intel Core i7 processor,

which is now going on 10 years old. And then we build for AVX2. And there's a number of packages, probably something like 500 to 1,000. I can do a grep here and find out later, which have an AVX2 build side by side, right? So it gets installed on your system, both. Okay. Right. And what happens is that at runtime, it decides what to do. So if you're running on an Atom, or if you're running on a 10-year-old CPU, or running on AMD CPU without AVX2, it will run the baseline. If you're running on anything that is newer than a Haswell, which is 2014,

you get the newer code, which is supposed to go faster. That's pretty interesting. Okay, well, Tiago, we got a couple news articles to discuss. Feel free to comment on any of these, and then we'll start talking more about your work with Qt and maybe more about Clear Linux,

okay? Okay. So this first one is a blog post on the Visual Studio blog, and it's actually a reference to an announcement from the Qt company. So Microsoft has had support for Qt in Visual Studio for a while now for Windows-based projects, and this announcement is basically that

if you are using visual studio for linux then cute is going to start adding support for visual studio linux projects meaning you would be able to use the cute visual studio tools to make linux projects so visual studio running on that in this visual studio running on windows on running on building on Linux, making Qt for Linux. Via WSL, I think. Yeah. No, I don't think it is. So Visual Studio, not Visual Studio Code, from what I understand, and I'm not a user of Visual Studio.

I'm a user of Qt Creator, by the way. So this is why. As far as I understand, they have added a feature where they connect to a Linux machine and remotely control it. So what they do is that they SSH into it, upload some source code, run the build commands, and then download the artifacts back to you. You're not going to be able to run the Linux binaries on your Windows machine unless you have a WSL, like you said, but this is just so you have the build artifacts. They can also control the remote application via GDB,

and then I don't know if they do X11 displays, exporting, something like that, but they can control the application. I think the original goal when they started this was to make server applications, so nothing graphical. So this is an interesting news that they are supporting

Qt-based applications, which are supposed to be graphical. It goes in line with what we want with Qt, which is multi-platform. So I suspect that what they want is that you compile on Windows, make it work on Windows, and make your application great on Windows, but also support Linux by testing that your code compiles and runs on Linux. It would be interesting to know if they do the same for macOS as well, because it shouldn't be too difficult to SSH into macOS and do the same commands.

I think there might be some legal reasons why they might not be able to do that. Well, they do support Visual Studio with macOS, but I don't know... Visual Studio Code, you mean, right? Or Visual Studio Code? No, I thought Visual Studio for macOS was a thing. I could be wrong. Maybe it's time for us to get someone from the Visual Studio for Mac OS was a thing. I could be wrong.

Maybe it's time for us to get someone from the Visual Studio team back on again to talk about some of these things. Visual Studio 2019 for Mac. Okay, it is a thing. Right, so that's actually a version of Visual Studio running on a Mac. I don't think there's a C++ compiler in that version, though. I think it's mostly for building the xamarin c sharp mobile projects well that's just useless though to our listeners it is yeah but uh i'm sure there's

plenty of users out there of it okay uh this next thing we have is uh an article from bjorn strewstrup on the iso cpp blog and it's on c++ 20 significance and uh it's basically some some notes uh summarizing some comments he made at the end of the prague meeting just talking about uh how much of a historical milestone c++ 20 was um you know some of the notes he has in here 30 years years of standardization, 40 years of C++, and the features that we've talked about that are making it into C++20, concepts, modules, and coroutines. He had an interesting note here that coroutines were, he says, the bread and butter for C++ during the first

10 years, but then they were taken back out because of implementation problems on Spark architecture. I'm not sure if I hadn't talked about that before. Yeah, I didn't know about that. No, that totally took me by surprise. Coroutines coming back. Very exciting. Anything else you wanted to add to this or comment on it, Jason or Tiago? I think it's great that we're seeing progress with C++, right? So I've been, we have here in Portland, Oregon, we have a very active C++ users group. And we have two committee members coming every month to the meeting

and they tell us about how the progress has been going. We had a meeting just after the C++ Prague meeting. And so they had a lot to tell us about. And I'm very excited to see these things going. I've been playing with some of the newer features, and there are a couple of others that I haven't had a chance to look at yet. I'm personally more interested in the lower-level ones,

so I really want to get to concepts eventually, but right now I'm focused on threading primitives. So there's a number of new interesting things like synchronizations and barriers. And I really want to understand how they work and how I can apply to make my software even better. So Qt, as you might know, we tend to roll out some of these primitives ourselves.

Eventually, I'd like to replace them so we understand what's in the standard, how well they're supported in other things, how they work and how I can replace my internals with what's in the standard, how well they're supported in other things, how they work, and how I can replace my internals with what's in the standard library and just remove maintenance load. I really would love to talk more about that process in your plans, but we've got – I'm just sorry, thinking like let's – okay, I'm going to dig into that bit once we finish the news in just a minute here because i really want to talk more about that yeah it makes sense okay and then the last article we have then is from herbstutter's blog and this one is move simply and i believe he's done a couple of these articles recently where he's going over uh some newer c++ features uh that are sometimes misunderstood

and uh going into his own explanation of them and like i said this one is about move semantics and you know he summarizes it just a few paragraphs if you're kind of the average uh user and then he goes into a lot more depth if you are like a library writer or advanced user um these definitely seem like you know good blog posts that i appreciate him putting out here and getting his opinion on some of these uh features yes anything to add there jason i did i was looking for a part of his article i don't't remember. I had something specific I wanted to address, but I don't remember what it was. And then there's a large Q&A, right, where it's actually discussing many of these things in terms of dialogue with the reader. So that's a very interesting way to put a blog out. Yeah, I think it's important to say, though, that most users can probably get away with just reading those first two paragraphs.

You hopefully don't need to know too much more about it unless you're really getting into the weeds. I would add an asterisk to his first two paragraphs that said, but best is to write your code in a way where you don't need move. Because I mean, that's I just find that to be true almost 100% of the time, if you can just return a value from a function and not think about, you know, where know where it came from whatever like been a more functional building build up of your library or whatever that can really simplify your code instead of thinking about moving objects around but i still can't find the specific paragraph but i remember now what it was that i wanted to bring up and it's where he says that any object like this whole question of what state is a moved

from object in and then he makes the argument that it's in the same that any object, like this whole question of what state is a moved from object in. And then he makes the argument that it's in the same state that it would be in if you called any other non-const member function. So it's like if you receive a reference to an object in your function, what state is it in? It is in a valid but unspecified state. That is the argument that he makes, that we should not think of move as being that special. It's just a mutating function. And I like that. I'm going to use that later. That's an interesting way to write it, because when he talks about, and this is what the standard says, it's in a valid but unspecified. And one of the questions

here is that people say, well, I'm scared about unspecified. Right. But, yeah, he's pointing out this is not very different from everything else. Initially, I remember when back in 2010, 2011, people were talking about move semantics. up with having a lot of objects that were in a state where the only things that you could do were destroy or assign something to it. Calling any other member function or trying to read the invariant, either const or const, was undefined behavior. You would crash or do something different. I remember those days. And I think that the C++ community came to the conclusion, this is not a very good thing to do, except for maybe very internal types where you know what you're doing. The best is actually

to keep it in a valid state where you can call any of the member functions. You just don't know what they're going to do. So take the example of a string, right? If you move from a string, and even if it's a string with a small object optimization, small string optimization, if it's big enough, the original string is probably going to be emptied out. So what is the size of a string after you've moved from it? It might be the original one. It might be zero.

It could be something different as well. Yeah. It could restrict itself to the bytes that it had on the small string optimization or a chunk of it i don't know like you can come up with a couple of ideas yeah i've been thinking for a while about making my own string class that after you move from it its current value as jason was here just to prove a point uh i haven't actually implemented that though that is a valid but unspecified state. But yeah. But more to Tiago's point,

her comments in here that if, you know, calling the size of a move from string is undefined behavior, then your string is broken, basically. But the interesting thing is that putting on a string JSON was here is actually a very interesting debugging technique. Right. Because you can catch the uses of putting on a string JSON was here is actually a very interesting debugging technique. Right.

Because you can catch the users of using a move from object, which is an unspecified state. Your program should not be depending on that by seeing that you had that value. I think that, I don't remember if it's Visual Studio, but one of the compilers in debug mode always initializes un-initialized variables

with a pattern, right? Yeah, CD, CD. CD, CD, for example. That's a good one as well. Because CD, I think it's also coming from the original, from x86. If you ended up accidentally jumping into that as if it were code,

it would execute an interrupt. CD is the opcode for interrupt. Really just interrupt 0xCD, right? This is also why you see CC because CC is the breakpoint opcode. But the difference that CC is an even number, right? And CD isn't. So I think that some people think that odd numbers are better for debugging. Huh? Well, I guess the numbers are, if you're looking at memory addresses or something, more likely to be an invalid memory address, although certainly not guaranteed, or an unexpected memory address.

I had no idea that CD was the opcode for interrupt, and that was the original reason to do that. Yeah, I know that. This is my suspicion. I know it is the opcode. My suspicion is because it's the interrupt. Another pattern I've seen, and by the way, since we're talking about this, is 0f, 0b, and that's because this expands

to the undefined instruction. So if you happen to jump into code that has 0f, 0b, you might execute a number of instructions that make no sense, but eventually you might execute a number of instructions that make no sense, but eventually you get to a defined instruction within, I think, within 16 bytes, and then your

program will crash. Right. That's a fun one. Yeah. I've not seen that one. I think the only pattern I've personally been exposed to and noticed was Visual Studio CD, CD initialization of memory and debug builds, I think. Yeah, thank you.

Okay, well, Tiago, we mentioned a little bit about how you started with Qt and KDE back in 2000. Do you want to get us a little more background on how you first got involved in Qt? Sure, how much time do we have? I started back in 1999 when I started looking into Linux and I was looking at opportunities on what to do. I was still at the university and I was trying to learn things

and somebody had asked me, so what do you want to work on? I took a few days and I thought, well, maybe I want to work on IPv6. This was brand new back then, was just coming online. I'm sorry, what year was this again? Do you mind? 1999. So we're still 21 years after this, and IPv6 is still completely not caught on. But the interesting thing is that this led me to figure out what browser can I work on that doesn't have IPv6 support yet. Firefox did back in 1999. So the next one was Conqueror, the browser for KDE.

And that's what led me to look into the sources for KDE and the sources for Qt as well. So I started back then, started contributing to the project. My first contribution was accepted in the year 2000. It was exactly a socket class for KDE, right, for KD Core, the library back then. And I kept on maintaining it, expanding my portfolio of classes I was maintaining. And eventually, I started in 2006 at Trolltech, where I began working on Qt itself. Interestingly, what happens when you get hired into Trolltech is that you get the maintenance of the things that you had complained about.

So I ended up also working on the socket classes, which is why when you read my bio, you saw that I wrote a number of the classes and maintained a number of the classes for Qt Network back then. The entire Qt Network access manager was the higher level, accessing HTTP, OHTPS, and things like that. That was also my doing with a couple of colleagues at the office then. In 2006, when I was starting at Trolltec,

KDE was also thinking of the switch from KDE 3 to KDE 4, which matched the Qt 3 to Qt 4 change and we were thinking should we re-standardize our inter-process communication mechanisms using something common with GNOME and that was Dbus and then I wrote the classes

to support Dbus in Qt and then they got accepted back also in 2006. I worked for Trolltech and then Nokia when Trolltech was acquired until 2011, which is when I moved to Intel, and I've been with Intel ever since. Part of my job has continued to be maintaining parts of Qt. I've since given up the maintainership of Qt Bus. I don't have enough time to continue working at it. Qt Network is maintained by other people these days,

and I have never been the maintainer of it. But Qt Core is still my responsibility. So I am the maintainer for it. I do read all of the contributions that I receive in any way relating to Qt Core. Sometimes I'm not the right person to review some code. So if you send something to State Machine or the animation framework, which are inside Qt Core, it's not my job.

I will try and find somebody else to review your code. But everything else, you can probably count on me posting a comment saying thank you for the patch and plus one, I'm not sure if I can approve this, let me find somebody else. Or plus two, this is good, this is approved, go ahead and click the stage button.

I want to kind of go back right to the beginning, if you don't mind, because this is approximately the same, let's see, 97, 98 was maybe the first time I used KDE, somewhere in that time frame. So did you ever actually succeed in your goal of enabling Conqueror for IPv6?

I did. So Conqueror supported IPv6 in the year 2000 and has supported since. And all of the browsers that we've had in KDE have supported IPv6, and most of the applications have also supported it. And what I tell people also with the support in the key classes is don't try to be smart. Then the classes will do everything for you. Don't try to assume something about it.

Don't assume that your address is a 4-byte IP. Don't assume that you can parse it this way or you can copy-paste it into a URL. If you don't do that, you're probably fine and the classes will just take care of it for you. So Qtcp server will bind to an IPv6 port which will accept IPv4 packets, connections. And if you use QGCP socket and you resolve a host name, the system automatically will determine whether you have an IPv6 address. If you do, it will try to use that to connect to the outside world. If you don't have an IPv6 address, it will first resolve the IPv4 and will use IPv4 to connect to the outside world.

And you shouldn't be even seeing performance degradation about this, because even if it decides to resolve both, it resolves both at the same time. So I remember this was a project back in the Nokia days as well, Nokia was interested in this, and they gave an interesting codename for the project, which was called Happy Eyeballs. So how did you actually go about testing it back then when you didn't have anyone to talk to? I think back then we already had Sixbone. Is that what it's called these days still? I think Sixbone already existed.

You could have tunnels that you could test things with. And of course, you can test it on your local network. And even these days, for example, I'm a subscriber of Comcast here in Portland. I have IPv6 on my entire network. So it's completely enabled. And whenever I go to change my VPS, for example, I changed from Germany when I moved to the US to a host provider here in the US, one of the first things that I was looking for is do you support IPv6?

And I excluded one of the big ones because they don't have support for IPv6. Wow. Yeah, I'm pretty sure I have support for IPv6, but I have still at this point really no idea what I'm doing with it. I'm pretty sure my network and everything has everything enabled, but I have no idea.

The main thing that slows me, and this is completely off topic, but the main thing that slows me down is I'm like, I don't know which routing options to choose on my cable modem. So I'm just going to ignore that for the moment, but not cable modem on my router, excuse me. So is Conqueror's rendering engine still independent maintained? The rendering engine for Conquer was originally KHTML. I think that KHTML still exists. It's still maintained somewhat, but it's not recommended for new projects.

So it exists for legacy. And newer applications, so for example, I'm looking at my email reader today. It's KMail. KMail, when it shows HTML emails, it's using Qt Web Engine, right? So it is not KHTML, but it's KHTML's indirect descendant.

Oh, okay. So KHTML gave birth to WebKit, right? So when Apple started working on Safari and they needed a web engine, what they did is that they took KHTML, and for a number of years, it was still KHTML with Apple patches. At some point, they renamed the project, called it WebKit.

A lot of companies used it and shared work with it. Chrome started with WebKit, and they eventually forked from WebKit and created their own engine called Blink. So today, it's probably like 20 times bigger in terms of code base because support for HTML has grown. But it's an indirect descendant of KHTML. Wow, that's pretty cool. I want to interrupt the discussion for just a moment to bring you a word from our sponsors.

Backtrace is the only cross-platform crash and exception reporting solution that automates all the manual work needed to capture, symbolicate, dedupe, classify, prioritize, and investigate crashes in one interface. Backtrace customers reduce engineering team time spent on figuring out what crashed, why, and whether it even matters by half or more. At the time of error, Backtrace jumps into action, capturing detailed dumps of app environmental state. It then analyzes process memory and executable code to classify errors and highlight important signals such as heap corruption, Thank you. Companies like Fastly, Amazon, and Comcast use Backtrace to improve software stability. It's free to try, minutes to set up, with no commitment necessary. Check them out at backtrace.io.cppcast. So I want to go back to Qt Core for a bit, which you said you're the maintainer of.

I think you said there's some parts of that that you're not really responsible for, like animations. What are the APIs that you are responsible for in Qt Core? So, strictly speaking, I am responsible for all of Qt Core. It's just that whenever I don't have the complete knowledge of it, I will ask somebody else to help me review the code. And this happens even for things I am much more familiar with. So, if you take, for example, the QObject object parent relationship, the signal slot mechanism,

I know how this thing works. But I know there's somebody who knows Zivitam better than I do. So whenever I see a commit coming in that doesn't have this person added to as a reviewer, I will go and add, hey, Olivier, can you take a look and give me your opinion on this? I will defer to him because I know he knows a lot more than I do. And maybe he has a couple of changes on the pipeline of ideas where he wants to take it.

And he wants to have the opportunity to express them and align the contribution with his ideas. So I will add other people. But if you ask the ones that I'm directly responsible for, and usually I'm the person who knows it best, it's probably going to be the classes I wrote myself

in the last few years. So I wrote, for example, QRandomGenerator, which is a wrapper around both random device and random engine. I think it's the Mersenne Twister. It's trying to do things the right way because we found a lot of people making pitfalls in seeding their random engines in C++.

Plus, we had a number of older code. When I introduced these classes, I went around through the entire code base and removed everything that was calling srand and rand because they weren't seeding properly they weren't very good i just try to make it easy and this is where we try to do things with cute which is make 90 of the work that you're going to do easy right so it is just one function call you call it and you get a properly seeded random generator and and that's it. Another one, QDeadlineTimer,

which is kind of like a standard chrono time point, but with other functionality, like trying to figure out, have I expired, have I passed the deadline, or how much time is left? So again, make things easy for the purpose of, I just want to set a time, a deadline. This happens a lot in low-level classes. Like, I want to wait for 30 seconds at most.

Set the deadline, pull your sockets, pull your file descriptors, and then has the timeline expired. Okay. So, you just said your Q random number generator is a wrapper around random device, and you mean the C++11 random device, right?

Yes, the standard random device, yes. Okay. And so that does imply that today Qt requires C++11 to compile? That's a good question. Yes, we do. So when we began Qt 5.0, we didn't. So that was in 2012. It wasn't an acceptable requirement

to require C++11 at the time, but starting with Qt 5.7 a few years ago, we did begin requiring C++11. So Qt today, we're about to release 5.15.

We've just made the alpha release. We do require C++11. Qt 15, right? We've just made the alpha release. We do require C++ 11. Qt 6.0 will require C++ 17. Oh, that's a big jump. Yes. So we hope to release 6.0 by the end of this year, and that's, I mean,

2020, C++ 20 will be out, so requiring C++ 11 was our choice. We had a lot of discussion whether it was an acceptable one because do we still need to support some compilers that don't have it? Is there a limitation? We're

really pushing towards C++ 17. We might have to leave behind a few platforms in terms of support because they don't have the necessary compiler. We're going to tell people, keep using 5.15 for however long it takes you to upgrade your platform,

upgrade your compiler to get with 6.0. So then you mentioned earlier, and now I get the opportunity to bring it back around, that for things like threading primitives, you want to move to those that the standard provides when possible, right? Yes. So does that mean with C++ 17 support, just like hypothetically, are you swapping out parts of Q file system with std file system?

We would like to see whether that's possible, right? So apologies for the non-answer answer. That's fine. The thing is, we want to reduce our maintenance workload, but we're not willing to compromise on functionality, especially the existing functionality. So let's take the example of SudThread.

We are not probably going to remove QThread at all, ever, because it has extra functionality that stud thread will not give you. It will not give you the signal saying thread is finished, will not give you the thread affinity that we have, signals and slots. So QThread is going to stay. But can we replace the back end of using PThread and Windows threads with StudThread? And that might be a possibility, right? So using it in the back end.

Same thing with file system, right? So can I replace the file system internals, which are a lot of code, especially dealing with Unicode paths on Windows? We might be able to, right? But this takes some looking into, and sometimes the replacement is more work than the ongoing maintenance. What I mean is this code exists for us, right?

We've had the code that does file system support on Windows for going on 25 years. Same thing on Unix, right? Ripping it out and adding something different might be more work and introduce more bugs than it's worth keeping the existing code. So we are willing to look at it and we are willing to always understand

where the standard is going and especially if it's going faster than what we can figure support out. And this is where the threading primitives become interesting. I can do this with assembly. I can write org directly with atomics. I can do all of this. But if the standard

has it all for me, and especially if it has for more platforms than I was able to write for, then it's actually a net win. For file system, I know that there are people looking at it. The good news is, at least on the front end, we're trying to accept file system

path variables, so you can specify your path and get from our classes the standard file system path. So we're going to offer front-end compatibility. And talking about a class I wrote, again, get that line timer, it does have support for interoperating with time point and duration. Okay.

Yeah, so if I could maybe pose a hypothetical, and I know you said you're intentionally not being committal about this, but just hypothetical to make sure I understand the stance. If you were looking at the delete file function in Qt and said, oh, we definitely can replace this with std filesystem delete, or whatever it's called, because of X and Y, we know this will work for our use case, then you would consider that a win.

You might just swap out the backend end and put in std file system delete and do it like atomically. You're not thinking, okay, we have to swap out the entire back end with all of standard file system. Yeah, that's a very good point. I think we could, especially because today what happens is that we have an implementation on Windows that calls delete file and we have an implementation on Unix that calls remove.

Right. So that means we have two files with the same function defined in different bodies. Can we merge the two with a single implementation that calls std file system delete? I think that would be a net win, right? And might be a good optimization. We could do it incrementally.

Just change delete, then change rename, and then change whatever comes next, right? Right. So that is the kind of thing that you consider, basically. Yes. Okay. Another good thing about file system, by the way, is that it has the API to not throw exceptions

but just return error codes, and that would be the API to not throw exceptions, but just return error codes. And that would be the one we would prefer to use. I wanted to ask about the little bit of an internet controversy that came up about a month ago when Qt announced some licensing changes. I just want to know what your opinion was that was on those licensing changes and whether you think they're really going to impact average developers and users of Qt? Okay, tough question. Tough question. You can't answer it for whatever reason. No, I can. I can, but I will not be giving a depth answer. Sure. The reason why they made the changes from at least what they posted online and talking to a few of the folks is that the business of the

open source, turns out what they're saying is that Qt itself is really good and customers aren't paying for just support on the open source version. So they just go and make applications and they use the open source version and they can. So they wanted to figure make applications and they use the open source version and they can.

So they wanted to figure out how can we provide value in the commercial version that doesn't exist on the open source version. So what they made were, I think they made three important changes. There are a couple of modules that switched the next release from LGPL to GPL, I think. Nothing touching the core part, so your current application, if you're still using Qt Core or the Qt Base modules, the QML modules and all of that,

they still continue to support LGPL. The second change was requiring your account. You can't download the binaries anonymously. And to be honest, this is the one that is affecting me the most because I have builds on my CI systems that I use those binaries. So how do I download something? Do I put my password on my CI system?

I don't want to do that. I'm waiting for them to give me like, here's the recipe we recommend for you to write third-party CI systems. And then there was the one about the long-term support releases. So we made 5.6, 5.9, 5.12, and we'll make 5.15 long-term support releases.

And these are going to be only to commercial customers going forward, right? So the existing one is up until 512. They will continue being available to everybody. 515 will be available only to commercial customers. That means after the normal support period, so 515 will be by normal available, but the one. So after the normal support period ends, there will be no long-term available to the public. If your company, if your use case needs it, you should be talking to sales and have a commercial support. That's their objective. So they figured that one of the value adds was that. So they asked me, do you think open source users will be affected? And I did a quick search around and it turns out I missed a few things.

Do Linux distributions use the LTS releases? And I found that most don't. So they keep up with the mainline. Or whenever they have their own LTS releases, so take Ubuntu, for example, they cut at the time that they made their own feature freeze, whether that was a cute LTS or not. So you see, for example, at one point they cut at 5.11, right? So they missed the boat for 5.12, I think.

Turns out I missed some of the releases in OpenSUSE. They were really trying to stick to the LTS. So they were complaining that, okay, so if you're not going to give us the LTS, we're not going to align anymore. We're going to go back to what it was three years ago where we're feature freezing on whatever the release

we had at the time, and then we're going to pester you with bug fixes. Well, okay. I do find your CI problem interesting because i am definitely involved in projects that use cute uh i mean and and have ci and is our they are all open source projects although uh for our use case we're doing custom builds anyhow because we need some custom flags on our cute build so i don't think what you're describing will end up affecting us. I'm not positive.

Yeah, the problem is that building Qt on a CI will take you, I don't know, half an hour. These machines usually aren't very powerful. If you get free CI services on the web. Right. And I've seen people complain that the build time's out, that their virtual machines get killed because it took too long. Maybe it's a matter of not building everything

and they didn't pay attention to this. I'm using a service that actually does provide Qt today on Windows, and for Linux and for Mac, I just download pre-built from elsewhere. So I use the Linux distribution as an installation of Qt, and I use Homebrew for Mac. But for Windows, I just depend on the service giving me a pre-installed version of Qt.

I wanted to switch to GitHub Actions because my projects are hosted on GitHub, and then I would have to somehow install. And I figured either I build, or I build and store the artifacts, but I don't want to pay for the bandwidth outgoing whenever somebody sends a pull request for me.

Could I store an artifact? So this is the kind of question I don't know, and I just were asking them, and this was also forced, in fact, can you look into this problem you created and give me a solution? I posted the question to the mailing list and saying, hey, tell me what your recommendation is. And I want them to tell me that they want me to use their binaries, but how do I download?

How do I install? What is the proper way to do an attended installation with their binaries? Yeah. So hopefully we get a good answer to that soon. Yeah. Yeah. If I find anything, I'll share. Sounds great.

Okay. So one of the other ways you've been involved in the Qt project is as a release manager in the past. Is that right? Oh, that was a long time ago, but yes. Okay. Well, maybe the questions then are still relevant, even if it was a long time ago.

It seems like a big job being a release manager for a project of that size. It is. And I really thank the current release manager, he's called Yanni, for working to this. It is sometimes a thankless job, nagging people, saying, future freeze is coming, make sure you're done, and we need to release, where's your bug fix? It is a thankless job sometimes, so a round of applause to Yanni. So on the topic of releases and CIs and all these things we were just talking about, when someone does do a pull request and you accept their pull request,

I assume Qt has a large dashboard that tests all of the possible configurations? Yes. Okay. So making a release hopefully is made slightly less painful by that if you can look at the dashboard and say everything is green. Yes. So it is. You have to go back 15 years on this. So when I started at ChalkTech in 2006, we did have a testing system, but it wasn't continuous integration. The term did not even exist back then, continuous integration.

So what happened was that people just pushed commits. It was perforce then, right? People submitted things. And every day, each of the machines downloaded, built, and ran the tests. And what we had was a dashboard saying, these many tests are failing. And for every release, the release manager,

and this is where I was beginning as a release manager, we went and nagged people, hey, this test that you're responsible for is failing on Solaris or AIX, which we still supported then, go figure it out, right? And that sometimes introduced or often introduced delays into the release because the test failures counts were high.

And then we had to make a decision, okay, these 12 we're going to accept and going to release anyway. We've improved since then. Going through many iterations and generations of CI systems. Our current one, the way it works is whenever you click the stage button on Garrett, it will do the testing on your contributions and everything else that was ready at the same time and will give you a pass or fail.

Right. So if you introduced any new failures, your commit will be rejected. So it's been approved. Everybody looked at it, said this is good, but introduced a new failure probably on something that you hadn't realized was connected. So your commit got rejected. You get a chance to update it and send something new. This, on the other hand, introduces instability when somebody else's commit that was tested at the same time broke the build, or when you have tests that are flaky and sometimes

depend on networking resources or they're timing sensitive, things like that. We have a few of those, and the QA team goes and tries to improve them as time goes by. But the good thing is, because we have this, the release manager can say, yeah, I know that everything that is in the repository right now has passed at least the first level of tests. The release process requires testing more. So this is where we go and test some other combinations

that aren't very common. This is where they make the binaries and try to install the binaries and figure out if everything is working. So sometimes they find things. The release meeting notes are public, so people can read them. And we don't usually have issues with finding things late these days. So having a CI system has allowed us to know more or less what the state is. It's more of these days discussing, there are a couple of reported

issues that are priority one or even priority zero that somebody needs to get attention to, or we need to make sure we've upgraded all of our third-party components. Who's taking care of that? The release, the feature review, right? So the API reviews and the new feature reviews for new minor releases have to be complete. And somebody hasn't done yet. This module hasn't finished theirs. So the discussion is whom do we nag to make sure this is done

and then make the releases. Okay. Since we're on the topic of release managing, anything exciting coming in Qt 5.15 that you wanted to talk about? The thing is most people want the interesting things on the graphical parts, and I don't work on that. That's fine.

I work on the nitty-gritty details, and a presentation I gave last year was everything but the UI. So I was talking about all of these interesting things you have in Qt that are not the UI, and if you read the blog announcements, you're going to be all about the UI and new QML features and new multimedia and web sockets is like, this is not what interests me. I've been busy with a couple of other things at work, so I haven't contributed much to the 5.15

release, so there's nothing I want to bring up. There is a number of interesting things coming, though, and the release announcements will tell people about them. Like I said, the alpha has been released, and the alpha usually is what we call feature-freeze already. So everything that you see in the alpha, everything that you look at the blog announcements, talking about what people have completed, is what you're try to make sure that everything that is going to be removed in 6.0,

so deprecated and removed in 6.0, is marked as such in 5.15. So the idea is people should be able to upgrade to 5.15, their existing code still working, turn on the warnings, find out how to port their code to not using these deprecated functionality, make it still work on 5.15, and then make the jump to 6.0. So you would do the upgrade, if you're not on 5.15 already, to 5.15 first as a two-step and

then to 6.0, turn the warnings on, find out which older functionality you might still have. We've had to add a few things that we want to really remove. So 5.15 has a couple of new things for things that are going to be removed in 6.0. So turn the warnings on, read what we write saying, this is deprecated, use this other function instead. And a few cases, there is going to be no replacement. So you have to either stop using or figure out a different solution.

Just out of curiosity, are you using the C++ deprecated attribute to communicate this? Yes. So we do use that, the one with a message. We try to always include the message saying, this is deprecated, use this other function instead, or use this other class instead. So whenever you get that warning, you know what to do and don't have to look up the documentation. The warnings aren't enabled by default.

So there are two things that you need to do, or you can do. One is completely disable the new function. So they're all behind if-defs. So if you disable the new function, you're going to have a hard error saying this does not exist. Or you can just turn the warning on, saying I want all of the warnings for everything that was deprecated until 5.14

or 5.15. And then you can do incrementally saying, okay, this now got deprecated. Let me figure out what I can do, how I can replace something. But if you're, for example, having to keep compatibility to 5.12

because some of your customers or some downstream users, you need to figure out that I can't replace with this other function that didn't exist in 5.12 yet, so I'll accept. I will not turn on the warnings yet. I'll do this at a later step where I can drop the older compatibility and then use the new functions.

Okay. Well, it's been great having you on the show today, Tiago. Thanks for having me. Thanks for coming. 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 robwirving 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 cppcast and of course you can find all that info and the show notes on the podcast website at cppcast.com