CppCast - CopperSpice

Episode Date: July 10, 2017

Rob and Jason are joined by Barbara Geller and Ansel Sermersheim to talk about the CopperSpice C++ GUI Library. Barbara is an independent consultant working as a programmer and software developer for over 25 years. She has been a featured speaker at more than a dozen trade shows and computer conferences in the US and on two separate occasions Barbara taught an extended class in software architecture and GUI design for the Panama Canal Commission in Panama. Ansel has been working as a programmer for over 15 years. Ansel worked for 8 years at a communications company designing scalable, high performance, multi-threaded network daemons in C++ and he is currently a software consultant for RealityShares in San Francisco. News 5 years of Meeting C++ Why you should really care about C/C++ static analysis Hotspot a GUI for the linux perf profiler Barbara Geller and Ansel Sermersheim Barbara Geller's GitHub Ansel Sermersheim's GitHub Links CopperSpice CopperSpice GitHub CopperSpice YouTube Channel DoxyPress CppCon 2015: Barbara Geller & Ansel Sermersheim "CopperSpice: A Pure C++ GUI Library" CppCon 2015: Barbara Geller & Ansel Sermersheim "Doxygen to DoxyPress" Sponsors Backtrace Hosts @robwirving @lefticus

This episode of CppCast is sponsored by Backtrace, the turnkey debugging platform that helps you spend less time debugging and more time building. Get to the root cause quickly with detailed information at your fingertips. Start your free trial at backtrace.io slash cppcast. CppCast is also sponsored by CppCon, the annual week-long face-to-face gathering for the entire C++ community. Get your ticket today. Episode 109 of CppCast with guests Barbara Geller and Ansel Sermersheim, recorded July 10th, 2017. In this episode we talk about static analysis and perf profilers. Then we talk to Barbara Deller and Ansel Sermersheim from Copper Spice.

Barbara and Ansel tell us about the Copper Spice GUI library and DoxyPress. Welcome to episode 109 of CppCast, the only podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? Doing pretty good, Rob. How are you doing? I'm good. You're all ready for your talk in Chicago, right? Yep. Three days of training starting on Wednesday. So by the time this airs, I'll be basically wrapping up with it. There you go.

But you are planning another one already, right? I don't have anything officially. Well, okay. So I am doing two days of best practices training at CPPCon in September. And I am toying around with the idea of setting up another training back in my home city, back in Denver,

while I have some time in August or September. Okay. Once you have the dates nailed down for that, we'll have to let everyone know who's in Denver. Yeah. Cool. So at the top of our episode, I'd like to read a piece of feedback. This week, we got an email from Paul. He writes in, hi, Rob and Jason.

Just wanted to say thanks for continuing to produce the podcast. I've been listening for about nine months now and always pick up something useful for each episode. I can't recommend any specific guests, but I would like to hear from some of the graphical and widget toolkit developers, whether that's one of the more well-known options like Qt, GTakeyMM, WXWidgets, or something like FLTK. Thanks from Paul. So this episode should be good for you, Paul. We're going to be talking about Copper Spice and QT pretty soon. We'll have to look into some of those other options, though. I don't think I've heard of GTK, MMM, or FLTK.

I think I've heard of WX Widgets, though. GTK is the GIMP toolkit. That's what's actually used to create the GIMP. And MM is a modern C++ wrapper around that since GTK is all C. And FLTK is, I think, native C++, but it's like a super lightweight thing. Okay. Yeah, we'll have to look into those and maybe get someone to speak about them. Yeah.

Well, we'd love to hear your thoughts about the show as well. You can always reach out to us on Facebook, Twitter, or email us at feedback at cpcast.com. And don't forget to leave us a review on iTunes. Joining us today is Barbara Geller and Ansel Sermersheim. Barbara is an independent consultant working as a programmer and software developer for over 25 years. She has been a featured speaker at more than a dozen trade shows and computer conferences in the U.S. We'll be right back. performance multi-threaded network daemons in C++, and he's currently a software consultant for RealityShares in San Francisco. Guys, welcome to the show. Welcome.

Thank you. So I'm kind of curious how you each got your start in C++ specifically, because you both have a wide range of software development experience, it sounds like. Well, I first got started in C++ because I was really tired of programming in assembly. And so C seemed like the next logical step. And it turned out that the compiler I ended up with was a C++ compiler, although pre-ANSI standard. And so I just started learning from there. And that was the rest of my career, basically. I've used quite a few other languages, but I keep coming back to C++ over and over again as I tell people.

The reason I love C++ is because it's never the wrong choice for any problem you're trying to solve. And I actually had started in Visual Objects, which was a programming language developed and then purchased by computer associates. And it's sort of a derivative of like a C++ language, but it doesn't have pointers and there's a lot of things missing. The language has since died and C++ was the best direction for me to go after that language stopped being maintained. Well, that's interesting. I've never heard of the visual objects language. I have heard of computer associates, although I feel like it's a name I haven't heard in a while.

I don't know if that's just my own experience lately. Visual objects was actually originally done by Nantucket, which was a company in Culver City. And it was actually an offshoot of D-Base. Okay. XM Ashton Tate people. I briefly worked at Ashton Tate and got involved with them. And there was no compiler. So it was sort of creating a compiler and then Visual Objects kind of turned in from actually sort of actually an offshoot of Clipper, which was Windows only and quite a few years ago. And Visual Objects just recently saw its demise. And most of those people have moved on to C Sharp.

Yeah, people like me who said, No, we, we need to be on multi-platform and most people in that arena don't understand that there's anything other than windows. So I, I keep standing on my soapbox trying to get them towards C plus plus, but it is a very hard sell. Right. Wow. And Barbara, what is this, uh, Panama canal commission where you were teaching software architecture and GUI design? Yeah, that was several years ago. And it was contracts actually for the canal. And this was back actually in the 80s.

And part of the problem down there is they don't have enough education and training. So rather than sending people who work for the canal to the US, they try to bring instructors down to the canal. And I did some projects many years ago. And it was quite interesting, the level of knowledge they had, and teaching them object oriented design. And it was really teaching them computer technology, and getting them to think in different mindset. So you were brought in to teach them software so they could write their own software to control the locks of the canal? Yes. Yeah.

Actually, it was. It was maintenance software. And one of the problems that they had with the locks is they were sending divers down way too many times. And about every 10 years, they actually go down and they repair a section of the canal. And they actually timed my trip down there during a repair. So I actually got to walk in the Panama Canal, and in a section that was drained towards the Atlantic Ocean. Yeah, it was quite exciting data, a scaffolding of about five stories. So I could understand how the canal worked.

So what they tried to do was make sure that the maintenance happens in a good order and that they're not having to send a diver down every time. So the software maintained tools and maintained everything, and they just needed to improve the software. So they needed a lot more technology. That seems like draining a section of the canal completely just needed to improve the software. So they needed a lot more technology. That seems like draining a section of the canal completely would be no small task.

It isn't. The section that I was in, this is before they added the other set of locks, what they do is they're miter gates on the older locks. And so they use dynamite to blow off the hinges, inflate it with helium and float the gates out. And actually, it was quite interesting. I got to go out, it was like two or three in the morning, and I got to go on a Greek freighter trip, ship through the canal. And it was just really a very interesting private tour with the head of the canal. And then so a section becomes exposed. And when you're walking down in it, you're looking up at a miter gate that's 50 or 60 feet tall, hoping nobody presses the button. And the gate opens, you're, fortunately, you're dead quite quickly. But yeah, it's, it was daunting. I just wish I had pictures.

Unfortunately, the person who took pictures, I never got them. But it was a lot of fun. And this is long before the age where we each had at least two cameras on us at any given moment. Yeah. Someday somebody will send me these pictures. They'll find me, and I will have them of walking down in the center of a canal and and stuff so well so if you're listening to this podcast right now and you remember barbara's trip you should send her the pictures send me the pictures yes to find out if you have any listeners down in panama i have no idea i think the guy with the camera was actually from columbia and

he snuck on the tour because he had not been able to get a tour of this for 10 years. But it was a once-in-a-lifetime event. Yeah. Okay, well, we have a couple news articles to go over, guys. Feel free to comment on any of these, and then we'll start talking more about Copper Spice, okay? Okay. That sounds good.

Okay, so this first article comes from Jens Weller at Meeting C++, and he is celebrating five years of working on Meeting C++, which is a pretty great achievement. He's obviously done so much for the community, running the conference for five years, right? And then the C++ user group meetups and the blogs. So I just want to say congratulations to Jens for doing so much for the community.

Is there anything you guys wanted to add on this? I just wanted to congratulate him. It's a great thing that he's doing with the conference. Yeah, and the conference is growing. Apparently the most recent one has had 600 people. It started off as just 150 attendees. Yeah. He does a lot just 150 attendees. Yeah. He does a lot of work for that conference.

Have you guys attended meeting C++ or spoken at it? No, we haven't had the opportunity to yet. I think it's been more of a timing thing. And we did talk to him and he suggested that we, you know, submit some paperwork and try to attend when it works into our schedule we just don't know quite how to drive the rv over over there so yeah i believe this kind of thing is actually possible you know you just have to take a couple of different uh ships across the uh north atlantic i actually heard of people who have done it but it's a lot of infrastructure to get there yeah Yeah. Yeah.

I met someone at an RV park who had driven their RV, if you will, driven it from Germany and Utah. So, yeah, I know people do it. Well, it has definitely been our new mode of transportation, and it's been quite fun. Very good. We're one of the few RV owners with routers and cell boosters and a lot of equipment. Okay, this next article is why you should really care about C and C++ static analysis. Jason, I know you always love talking about static analysis tools. What do you think about this one? I mean, it covers the main free tools cbp check and clang static analyzer

but then it calls out at the end here this uh cbp depend has this uh cq link language that you can use for directly querying your parsed code and i thought that was interesting. I've not used CPP to pen before. Yeah, I definitely was not aware that it had a query language built into it. That's pretty cool. And I also like the article kind of points out, we always talk about how great static analysis is, but it's worth pointing out that if you're not using static analysis,

you could be losing out on a lot of future developer time when a bug comes up that the static analysis could have caught for you. Yeah, that's definitely true. And there's a place for static analysis, but I have to say, I've been really, really enthused by the quality of the, um, the, uh, sanitizers in Clang recently. The false positive rate is zero, which means you can really invest a very small amount of time in it and get a huge improvement in your code base

because every time it hits a problem and reports it, you know you really have something you need to take care of in your code. Yeah, I agree with a minor tiny caveat that I believe I've seen a couple of false positives from GCC's implementations of the sanitizers. Ah. I haven't used the GCC sanitizer, so I haven't run into that.

I've seen just a couple of cases where it passes with flying colors on multiple versions of Clang and multiple versions of GCC. But like one version of GCC will crash with an error in the sanitizer. And I'm like, it has to be that version of GCC at this point. It's likely, although my procedure for writing correct multi-threaded code these days is write the code, prove that it's correct, run thread sanitizer on it, and fix all the bugs that it found. Then the second part of that, which I discovered recently, is then prove that you are getting a false positive from thread sanitizer, spend a little more time debugging, and then realize

why you were wrong and it really is a bug it's write far more than I am which is sufficient for a lot of my purposes I completely agree although I've never actually had thread sanitizer catch an issue I don't think but address sanitizer many times but I don't do the level of multi-threaded programming

that you do if you're writing lock- of multi-threaded programming that you do. If you're writing, um, lock free multi-threaded programming, it will catch some issues because you will have some, I believe, uh, Tony gave us, uh, a rule about lock free multi-threaded programming. Yeah. I think I remember. Yeah. I believe it was a stop just yeah right lock free code yeah okay um this next article uh is a new tool uh a hotspot which is a gui for the linux perf profiler um i haven't worked with the linux profiler myself but uh it looks like a pretty powerful guI. Jason, I'm wondering if that's something you might find yourself using. I might. I have not messed with this personally. I tend to use the output from Volgrind's Callgrind tool personally. But do you guys, Barbara, have any experience with this?

I've used Valgrind quite a bit for many years. And I was actually kind of excited to see this because there are lots of things that Valgrind does very, very well. And so usually you can get away with Callgrind or Cachegrind as your source of profiling data. But if what you want to profile is spending most of its time, not in user space, like you have some really slow sys calls or, um, you know, you're maybe working on a kernel driver or something that's very IO bound, then those won't help you at all because they can only profile user space instructions. So the huge benefit to perf in my experience, and I haven't dug into it as much as I'd like to, is that it is capable of profiling all CPU cycles, whether they're on the user mode or in the kernel, which can be really helpful. You can see which paths you're

exercising in the kernel and how you might be able to rearrange your code to be more efficient at the syscall level interesting okay okay it's also just better data because it's gathering data right off the raw performance counters on the chip oh is that what it does i did not realize that yeah perf is actually a framework that hooks directly into the hardware performance counters so you know that they're correct yeah i do a significant portion of my development in virtualbox or had been and virtualbox does not support emulation of the perf counters but vmware does and i recently moved to vmware so i need to revisit how i do performance analysis now that i actually have access to those counters for the first time. Yeah. Maybe you can put hotspot to the test and see what you think of it.

Yeah. Okay. So for listeners who haven't heard of copper spice, Barbara and Ansel, what exactly is copper spice and how does it relate to QT or cute? Well, copper spice actually was derived from Qt. And really, the history is, I feel, quite important. I was using Qt as a GUI developer. And every time I turned around,

I hit a problem. And Ansel and I work in sort of the same office area, and he kind of saw me strangling myself a few too many times. And it became kind of funny in a way. So after a while, it was, we need to improve this. We need to do something because there were just too many obstacles. And after looking at things, the idea of actually contributing to Qt became very difficult. So our vision really was to make the product better. But there were problems in what it would take to contribute to their product. So we spent a lot of time talking about this and realized we really needed to develop a better product. A large part of what led us to strike out on our own rather than contributing our changes back to Qt was because our vision was just fundamentally different from where the Qt community is going. I mean, I understand the Qt business model. They have a perfectly good software product, and a lot of people do a lot of great software with it.

What we wanted to do was go in a different direction and really bring it up to code with modern C++ design, both from the external API point of view, but also on the internals. We wanted to replace a lot of the internals, the build system, and really just bring it up to code. Do you want to go into some specifics about what exactly these differences were that you saw between how you want to do things and how Qt was doing things? Well, one of the things is understanding the mindset of most Qt users. And this isn't everybody, but a lot of Qt users, they actually don't, it's not that they don't know they're using C++. Their idea is to insulate themselves from C++. Most of them aren't fans of STL. And they like Qt because it's not the STL, because it's not C++. So it's a completely different mindset.

The common comment that you'll see on the forums that I've seen here and there is people saying, I use Qt because I don't like C++. Interesting. It is a completely different approach. And there are C++ people that will use Qt. And when they do, there's things that bother them. And Qt people just think, well, we were first. We did it this way and STL copied us. So you should do it our way. Again, we have nothing against what they did. My hat's off to everything the trolls did, to Nokia, to Digia, to the Qt company. They did a great job, but the direction they were going is not what we wanted.

One of the things we recently did is we just replaced and refactored all of the containers by leveraging the STL. All of their containers in Qt are hand-rolled. And so this results in a lot of issues. For example, only in fairly recent versions of Qt did they support things like reverse iterators because they had to implement them. They weren't based on top of any other container. We just got reverse iterators for free because they're built into the STL. It's been an ongoing battle for them against basically the language in terms of having to keep up with adding move semantics and adding templates where they need to be, supporting variadic templates in the places that make sense and things like that. The other major difference, and this certainly isn't the only reason why we started Copper Spice, but it was sort of the catalyst.

The catalyst. This is why we started thinking about the question of do we want to develop this, was working with a tool called Mock, which is part of Qt. It's part of the build process. It's used both for building Qt itself and for user applications. And it's the meta object compiler. It generates code that has a bunch of string tables that are linked into your application because there's a lot of dynamic functionality in the signal slot and meta object system, and they need a lot of reflection data. And obviously, reflection is not built into C++ yet. I know they're working on it, but it's making its way very slowly through the community.

And having mock as part of Qt, and it's been there since early 2000, I believe. I mean, this was a great way to add reflection and introspection to the language or to Qt itself. The advantage of C++11 was there were ways to remove mock and maintain the exact functionality. We did see various threads on various forms saying it's not possible it is if you're willing to use templates it is if you're willing to write some some fancy templates and one of the talks that we did um i think it was in 15 in seattle was about our um compile time counter, which is what we used to implement everything we need to set up

reflection. And we were able to completely remove mock and the mock tables, which greatly reduces the internal code. And getting rid of mock then allowed us to get rid of their build system. In the core library for Qt, we were able to remove about a thousand if-defs because the core this was one of the reasons why we wanted to re-architect the system, because Qt is built using a build system called QMake. QMake is written in Qt. Q requires, sorry, QMake to then throw it all away and start over and build the entire library. And it makes the core library very difficult to maintain because it's built in two different scenarios. So people have said, oh, well, that's all you wanted to do. Getting mock isn't a big deal. It is a big deal.

It affects compile time problems. And as Ansel was saying, it makes it hard to maintain. Our version of the core library in Copper Spice is cleaned up. We've also removed some of the antiquated compilers that don't support C++11, which is right now our lowest common denominator, although we'll probably be moving to 14 by the end of the year. That's a choice we're in the process of making. Another factor in all this is, you know, a lot of what we just talked about is sort of quality of implementation issues, and it makes it difficult to maintain the library internally.

One of the things that was so frustrating when Barbara first started using Qt was the fact that mock has to be run on your code, and so your code has to be something that mock understands. And mock doesn't understand templates, which means any class that needs to participate in the signal slot system or interact with the GUI cannot be a template, which for Qt programmers is no big deal because this is how they've been trained to think. And you can always structure a problem in such a way that you can solve it in that fashion. But for somebody who's been using C++ for a while and comes to the library, then to be told,

well, you can't use templates in half of your code, it's kind of frustrating. One of the other things that struck Ansel was, here I was writing this GUI application using Qt, and he said, where are your deletes? I see a lot of news. And I tried to explain to him that as a Qt user, you don't delete anything. All deletion is done automatically for you as the main Q object is destroyed.

Right. At which point he made a lot of very funny faces. When we tore through that in the process of enhancing the signal slot system in Copper Spice, we actually found that there were some problems in destruction, which we fixed. Some problems in Qt's implementation of destruction? Of the destruction, yeah. Yeah, there are a few places where the Qt object model, which we have inherited and are working on updating, says that every Q object, which includes anything that shows up on the screen plus a whole bunch of other classes that are internal. Every QObject has a parent, and your parent is responsible for your destruction. So it creates a hierarchy of objects, and when the root node gets destroyed, or for example, when a window gets destroyed, all of its children, which are all the widgets on that window, get destroyed by the parent. And this is a perfectly usable metaphor for dealing with memory management. The problem is it doesn't play nicely with modern smart pointers because you can't have

a, you know, a Q widget that you're working with and also have a shared pointer to it. So it makes it kind of difficult to it often makes it difficult to bridge code that's written in more idiomatic modern C++ into a GUI written in Qt because you have two different object models operating. So now in your code, you've gotten rid of that relationship? That part of it we have not yet been able to get rid of.

We're working on that. A lot of our focus was removing, again, in the beginning it was removing mock and making sure that everything worked with both CMake and AutoTools and the buildools and the build systems and working through the containers. It seems like every time we turned around, we found something like all of a sudden we found atomics were broken. So we had to stop and fix atomics. There's a lot of things in there that really need correcting. And that's what we're doing a piece at a time. And then of course, people like Charlie Bay tell us, please go fix the signal slot mechanisms.

So we wrote a standalone library and removed the signal slot system from within side of Copper Spice and then reintegrated it back in with a separate library. That's the types of things that we're doing. We really want to bring Copper Spice up to a place where it does use modern C++ and people can contribute to it as a C++ developer and feel like they're not working on a project that is 20 years old. So I'm curious if you had to make any compromises. Like if I'm a cute developer, say, and I want to jump into Copper Spice, am I going to be like, oh no, they removed my favorite feature X or something? Very, very seldom.

There are a couple of things here and there that we have removed. By and large, those things were already deprecated in Qt. And usually the reason why they're deprecated is because there was a better way to do them by the time C++11 came around. For example, there's one class that was basically a workaround for the fact that lambdas didn't exist. And that class turned out to be very difficult to support. But since we require C++11, lambdas are available, so it has no reason to exist. Okay. So that's the majority of things that you'll see is there are 99% source compatibility. There were a few very obscure classes, which were

often not even documented that have been removed for implementation reasons. And in the process of moving, we had to rewrite a lot of core and the core library. In terms of using some of the other Qt libraries, bringing them forward, I actually wrote a small parser to take the header files and convert them from the Qt syntax to the Copper Spice syntax, which is something, of course, you could do by hand, but why bother? And that is a small project called Peppermill. And Peppermill is something we actually released. So any Qt user that wants to move to Copper Spice, you run Peppermill one time on your header files, and it changes the syntax, which is just a minor changes, but it is annoying

to have to do that by hand. So that is a small program that we have available. And then from then, you're just using CopperSpice with more functionality in the sense that we've inherited more things by fixing the signal slot system, by fixing containers. We're in the process of redoing the string system as well. So Peppermill is able to completely convert an existing Qt application into using Copper Spice? Just want to make sure I have that right. Yes. The vast majority.

Yes. The typical case, and we've seen this in a couple of different instances with people who have migrated, is that the longest part of the migration process is rewriting your build system from QMake to either AutoTools or CMake. That's really it. Wow. The source code is just a direct translation, and for the most part, it just works out of the box. Yeah.

We had some internal applications, a recipe program, a tax program, some things that we had that took about 20 seconds to convert, but again, doing the new build system files, that was a little more complicated. But nothing tragic. All of the Qt programs that I have worked on used CMake anyhow, so it seems like it would be very easy

to move over from what you're saying. If you're coming from CMake, it's pretty straightforward. I'm curious if we could dig into the containers a little bit, if you don't mind, because you've mentioned that you've done a lot of updating of the Qt containers, and I'm left with the question of why update and not just throw away and replace with the C++ containers? That's an excellent question. And the main reason is source compatibility. I mean, your questions you were just touching on is,

you know, how hard is it going to be to port my existing application to Copper Spice? Okay. And if we got rid of QVector, QList, QSet, and so forth, then you'd have to go through and refactor all your code. What we've done is make all of those containers a zero-cost wrapper around the underlying STL containers. So you can use either one. Like I said, it's zero-cost round-trip. You can move from one to the other, and it maintains source compatibility.

And in addition to the other, and it maintains source compatibility. And in addition to doing this, we were able to enhance, some people like append and insert, some people like pushback. So we have added a bunch of methods to QVector, QList, QMap, QHash, to all of these. So if you like the syntax of STL, you can use that. If you like the names of the methods that of STL, you can use that. If you like the names of the methods that Qt had, you can use that. So everything does become a wrapper. One of the other things about the containers is if you read some of the internal stuff with the Qt company, they absolutely do not advocate using Qlist. They use it internally quite heavily,

but they have absolutely said it has problems, but they can't stop using it. They always say, just use QVector, don't ever use QList. But then if you ask a Q object for the list of its children, it comes back as a QList. So you can't avoid it as a container.

It's baked into the API everywhere. In Copper Spice, now QList is just a deck. And it's performant and efficient, and it doesn't have any of the kind of surprising behavior that QList can have on occasion. But if you were a Qt user, and you didn't open up Copper Spice, you wouldn't really know. I mean, it would just look like a QList that actually works. One of the side effects of QList is their QList uses copy on write. And we have discovered some very interesting places where they depended upon the lack of invalidation of iterators in a copy-on-write container when the copy you're holding onto is modified but somebody else has a copy.

And so your iterators aren't invalid. They're just pointing to somebody else's container. Okay. We severely broke, for about a week, tabs and tool tips and toolbars, anything that used a rectangle. And it took about a week to dive into code. I mean, even looking at the Git repo and trying to refactor from that did not help. There was a line of code we found buried deep that we deleted because it did nothing. Well, we thought it did nothing. It turns out that with a copy on write container, a completely apparently dead line of

code that just makes a copy of a container and does nothing with it actually has the side effect of pinning that container in memory so that you can say, get a couple of raw pointers into elements in the container and work with them without fear that the, the, uh, uh, pointers will become invalid as you modify the container because it's really pointing to the old copy. And there, there was no comment that, that this was a deadline of code or useless so we were good

people we just deleted it we thought we were doing a great job and once we found it and it was actually about three lines of code for us to rework it it turned out we made the code a lot better but it was the week trying to find what we broke. I think we could do an entire session at a conference titled Copy on Right Considered Harmful. Yeah. Well, no, and all this time that you've spent with Qt's versions of these containers, have you found anything that you thought, well, the STL containers could really use this feature,

I'm going to make a proposal to the standard? No. No? standard? No. No. Okay. No. The only place where you really get into arguments on that is people who consider the method maiming in the API superior to the STL. Like Barbara was saying, append versus pushback, and saying append sounds more natural.

But that's not really something that's going to make it through the standard, nor does it need to. They've already had those naming wars. Yeah. And you could probably argue until your face was blue about what exactly you're doing. Are you pushing something back or appending something? Because it might reallocate. Yeah. I have to say I like insert and append, and Ansel doesn't,

and so now Copper Spice can make everyone happy. You can use whatever method name you like. It is a wrapper, and there's no cost for it. The other thing that happens with the containers is they support both Java-style iterators and STL-style iterators. And so we changed how the STL iterators were implemented in terms of the wrappers that we added. Yeah. One of the major differences that we got for free was the fact that now for most of the containers, for example, a QVector iterator is just a using for an STD vector iterator. It's the exact same data type because we can have exactly the same semantics. And that means that we get much better optimization from the compiler

because the standard library can take advantage of the fact that they don't care about being standard compliant necessarily internally. I want to interrupt this discussion for just a moment to bring you a word from our sponsors. Backtrace is a debugging platform that improves software quality, reliability, and support by bringing deep introspection and automation throughout the software error lifecycle. Spend less time debugging and reduce your mean time to resolution by using the first and only platform to combine symbolic debugging, error aggregation, and state analysis. At the time of error, Backtrace jumps into action, capturing detailed dumps of application and environmental state.

Bactrays then performs automated analysis on process memory and executable code to classify errors and highlight important signals such as heap corruption, malware, and much more. This data is aggregated and archived in a centralized object store, providing your team a single system to investigate errors across your environments. Join industry leaders like Fastly, Message Systems, and AppNexus that use Backtrace to modernize their debugging infrastructure. It's free to try, minutes to set up, fully featured with no commitment necessary. Check them out at backtrace.io.cppcast. I have a question.

Have you run any performance analysis on a Qt application and an application that's been converted to Copper Spice to see how much performance you've gained from it? Well, nothing quantifiable to the level that I think we would like. But we have had significant user perceivable improvements in a lot of applications. One of the applications that we developed is DoxyPress. And at one point, we had a debugging version that we were showing to someone. And we made it very clear, you know, this is a debug build. It's got a lot of test code in it. It's going to be very slow.

But give it a try on your application and see how it does for you. And they came back and said, if this is the debug version, I'd love to see the release version because it's an order of magnitude faster than Doxygen was. And we attribute a good portion of that due to the fact that we are using more of the built-in standard library than the Qt libraries were. So go ahead and tell our listeners, if you don't mind, what DoxyPress is then. So what happened as we were starting to get to a point where we thought we were going to be releasing Copper Spice, we realized we needed an API. We needed some documentation for the API. And Ansel said, hey, go look at Doxygen.

That'll be a great thing to use. And I tried for about two to three weeks. And no matter what I did, it could not parse the templates. It couldn't parse quite a bit of the API that we had with Copper Spice. So we started looking at Doxygen. And we actually did contact the maintainer and tried to work with him a little bit. He wasn't sure he wanted to make many changes. So we said, okay. And so we just took Doxygen. And we did DoxyPress as derivative work. And well, I got to learn a lot about Lex parsers because I'm the parsing person in this operation, and it is quite humorous and also embarrassing.

They use Lex, and so I figured everybody uses Lex. Ansel kind of forgot to tell me that you're supposed to be using Lex and Bison, and I just thoughtx was the parser and it was it was quite an interesting experience, and JavaScript in the same parser. Same parser. And this is DoxyGen, what they were doing. This is DoxyGen.

And so we maintained that. However, what we realized was using a Lex parser and maintaining that was hopeless. So what we've added to DoxyPress is we've added the Clang tooling. And we use Clang for the parsing, which was great. And it involved definitely writing some code to interface it. But the nice thing is we sort of get everything for free. And at one point, we were showing DoxyPress, and we showed somebody that something was marked virtual in the output that had not been marked virtual in the code.

And they actually started clapping, going, that's exactly what should happen. So Clang is the way to go. We haven't found the equivalent Clang for IDL and, and some of the other things, but, but as we move forward, we'll enhance those parsers so they work better. But our main focus with DoxyPress was to be able to do C++. Because that's a language that's very poorly served by the existing documentation generators out there.

I mean, Doxygen just couldn't handle our code in Copper Spice. it's very poorly served by the existing documentation generators out there. Doxygen just couldn't handle our code in Copper Spice. And we have over the last year and a half or so, two years, with DoxyPress, greatly enhanced it and changed it. The original version of DoxyPress, and there may be some remnants of it now, it does actually use some Qt 1.9 classes that are in, not in the wizard part of Doxygen, but inside of Doxygen. And these are all containers that are pointer-based. What version of Qt are we on right now?

The current release, I believe they're on 5.8 or 5.9. I think it's 5.9. 10 is coming out. So 1.9 is definitely not maintained. And Doxygen was a great product. Started back in the late 90s. In fact, I think the Qt,

I think the Troll Tech people had used it. So I think what he's done is taken some of the classes he wanted to use, taken them out of 1.9 and put them in the product. One of the first things we did is we linked with Copper Spice. So we got everything in an upgraded version. Unfortunately, some of the walls we hit, having moved from pointer-based containers to some of the value-based containers, was pretty startling. Like what? Well, so one of the behaviors of the containers that it was using is if you accessed an element that was off the end of a container,

instead of failing, it just returned an all pointer. Okay. So there's not necessarily anything wrong with that, but if you want to refactor that code and make it use a container library that actually gives you an exception or an assert when you access off the end of a container, you will hit a lot of out-of-bound errors because there were innumerable loops that were just, while the element isn't null, keep incrementing the index. Okay. And it was difficult to track all of those down. We eventually had to search the code for bracket.

Yes, when your best plan is let's grep the entire code base for open square bracket, you're in a pretty dire situation. And it was the best plan, and we did. We did. That's what we did. The first one of these that we hit, it was insane trying to find it. It was just a hard crash that was impossible. We tried every sanitizer, analyzer, and everything.

It was brute force printfs to find it. And then once we did again, we searched for open square bracket. Were you just able to replace those with ranged for loops and everything was good moving forward? Some of them were ranged for loops. Some were just testing, are we at the end? I mean, is this a valid, are we the valid place in a container? Fixing the code was easy once you could find them.

I mean, that took like two seconds. At one point, we decided to change. It's all raw pointers in Doxygen. And at one point, we decided we really needed to switch a section of the code to shared pointers. Because there's this insane inheritance that goes on in terms of these dictionaries. So we decided to take the hit. And we just changed all the H files. And I think the following compile was well over 20,000 lines of errors. Wow. Well, that could just be one template, though.

Well, that is true. I'm actually rounding. There were about 20,000 lines of errors. There was about four or five lines per template sometimes. And we actually changed our error output routine to highlight certain things in certain colors temporarily so we could actually see it. It took about three weeks to fix.

Yeah, when it's actually worth developing a new part of your syntax highlighting system to highlight your error messages. Yeah, which is what we did. We stopped for an hour and we did that. There's a lot of things. Again, it's a great product, but it needed a lot of modernizing. It needed to be brought up.

There was a section of code that it was about 200 or 300 lines. And it was just a function that was like, if you have one parameter, now if you have two, all the way up to nine, we looked at it and we said, variadic template. And so we placed around 300 lines of code

with less than 10 lines of a variadic template. I don't know if it runs faster per se there, but it's definitely more readable. And it's a lot of things like that that we were able to optimize. Question on modernizing. You mentioned earlier that you were thinking of switching the baseline of Copper Spice

from C++11 to C++14, is there anything in C++17 that you're looking forward to for either Copper Spice or DoxyPress? There are a few things. My take on this is similar to a friend of mine who had said that most people who are on 11 really ought to be on 14 because 14 was just the point release that fixed a lot of the missing features in 11. Right.

For example, the generalized lambda capture and all those kind of things. So we're definitely looking forward to moving to 14 because that cleans up some places where we've just had to work around some annoyance. A lot of the stuff that's going into 17 is nice to have, but not necessarily compelling from a library point of view. The, like, destructuring bind is a nice thing to have, but it's just syntax. And so there's nothing in 17 that's compelling enough to make us want to drop

compatibility for the 14 compilers at this point. Yeah. Okay. But we could be persuaded. There are a lot of there are a lot of things in the standard library in 14 that we wished we had had when implementing

a lot of the registration system for Copper Spice but we weren't at the time able to use them because we couldn't get a C++11 compiler on all the platforms we wanted to target we couldn't get a 14 compiler on all the platforms we wanted to target. I'm sorry, we couldn't get a 14 compiler on all the platforms we wanted to target. So we had to, for example, implement our own index sequence.

One of those things that's in 17 that would be very nice to have is invoke and apply. But again, we've implemented that already, so it's just a feature in the standard library versus having it in our code. There's no advantage in that case to moving to the version in the standard library because it can't be implemented any differently. So one more question I had about Copper Spice. It sounds like there's still lots of ongoing work that you're making to make it even better. But is it production ready? Are people already using it in production GUI applications?

Oh, yes. Absolutely. People are using it in production. We're using it. I mean, obviously, we're using it with DoxyPress. It has been out there. It can absolutely be used. The thing is, it's just the more we put into it,

the better it gets, which is why we would love to have more contributors. A lot of the contributors we've had up until now have been people who have worked on the build systems, testing, documentation. We've had a few people, somebody submitted some stuff for DoxyPress, but we would love to encourage people to contribute to Copper Spice. Actual real code, although we do love the testing and to know that we broke on Dragonfly, which was probably not the operating system of Linux that we needed to support, but we can support Dragonfly. That sounds like a good one.

But having contributors be part of this, that's one of the key things that we wanted to ask for. We feel like it's a fun project, but also it's large enough that if you're somebody that likes networking, redo the networking module. If you're somebody who wants networking, redo the networking module. If you're somebody who wants to fix up multimedia, then work on that. There's nothing off limits. We're open to anyone who wants to contribute and work on any section.

Is there any particular section that you need the most support for right now? Contributors? support for right now contributors um there's a lot of different directions we'd like to see things going in i mean barbara just mentioned networking because we know there's there's a lot that can be improved there in terms of performance um there there is a lot in copper spice and it's um i would say a-rich opportunity for people who want to come in and either pick an area of expertise that they already have or take on a project to learn more about a particular domain. There's a entire printing subsystem that deals with all the nuts and bolts of PostScript, PDF, platform-specific, you know, rasterization, all that kind of stuff. It's really a full featured framework. So pretty much anything that somebody is interested in is represented there somewhere. I know we would like to see

somebody help us with the QFuture and QPromises, which aren't quite implemented in an STL fashion because of the fact they had to deal with signal and slots and because Qt was bound a little bit with how mock works with signals and slots. So there's some improvement. We have a very long list of suggestions. We would love to see S3 support added because we think that would be an advantage. So we just need somebody who knows how S3 works and would like to add it into the product, sort of things like that. And if somebody wants to work on some of the core stuff, that is available as well. It's probably just an endless project of things you can learn and add. So yes, if you're out there listening to this and you're interested in some particular part,

please drop us a line. It is very likely that the part you'd like to work on, we've been through at some point and said, boy, we'd really like to clean that up. If only we understood that problem domain or something to that effect. Right. So last question I had, before we got on the air, you were mentioning that you're going to start working on a video channel. Do you want to put in a little plug for that? Yes, we'd love to. Thank you. We're about to set up a YouTube channel for Copper Spice. And our aim right now is to put out a video every other Thursday. And we're hoping to have the first

one out this week as we're setting up video and cameras and lighting. And these are videos that will run about 10 to 15 minutes. And they'll cover topics of Copper Spice and DoxyPress. We're going to do ones that just cover, you know, what we learned with the containers, why you should use, you know, whether you should use inheritance or composition. So these are going to just be videos that we do, mostly going over slides of presentations we've done, explaining Unicode, the string library we've worked on. And then also branching out a bit into

things that we didn't feel we could do an entire session on at a conference, but when you break it up into small, bite-sized pieces, it might be of general interest. So we're going to be doing a series on multi-threading and our signal slot library, some more general topics in C++ about data types and expressions,

because we've actually learned a lot along the course of becoming C++11 and now 14 programmers. And for example, we had taught a class in C++ 11 to a group of programmers looking to move up to the 11 standard. And we discovered a lot of programmers who are still at that level and who would like just a really proper introduction to the fundamentals of 11 and helping you understand the language well enough to wrap your head around R-value references and forwarding and things like that. So we're going to be doing a whole series on that as well. I think we have topics set out for about the next two years. Because they're small and, like I said, just every other week. Assuming everything works, like I said, just every other week, assuming everything works. Like I said, the first one should be out this week.

We did set up the YouTube channel. Nothing's there quite yet, but it should be by the end of this week, assuming all the hardware works. Okay. Well, we'll put a link to that in the show notes and that should be airing around the same time as this episode. So where can listeners go to find you online and to go download the Copper Spice libraries? So you can find us at www.copperspice.com or.org.net, but.com is the main site. And from there, you can get links to information about us. There's a code link to our GitHub account. You can find all of the presentations that we've given at various

conferences and documentation on all of our products. You can also reach us directly via email. I'm Ansel at copperspice.com. That's A-N-S-E-L. And I'm Barbara at copperspice.com that's a n s e l and i'm barbara at copper spice.com and we also have a form that is also linked from our website so pretty much from the website you can get us through the github and we will make sure there's a link to the um the video channel on the website as well or just put copper spice into your favorite search engine. You'll find us. All right. Okay. Well, it's been great having you on the show today, Barbara and Ansel. Thank you. Thank you very much. Thanks so much for joining us. Thanks so much for listening in as we chat about C++. I'd love to hear what you think of the podcast. Please let me know if we're discussing the stuff you're interested in, or if you have

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