CppCast - STLab

Episode Date: July 29, 2021

Rob and Jason are joined by Sean Parent and Dave Abrahams. They first talk to Dave about his history with C++, Boost and the Swift programming language. Then they talk with Sean and Dave about Adobe's Software Technology Lab and their plans to focus on Concurrency in C++. News A Neat trick with consteval Constexpr memory allocation Comprehensive Catalog of C++ Books Links stlab stlab on GitHub Sponsors C++ Builder

Episode 310 of CppCast with guests Sean Parent and Dave Abrahams recorded July 22, 2021. This episode is sponsored by C++ Builder, a full-featured C++ IDE for building Windows apps five times faster than with other IDEs. That's because of the rich visual frameworks and expansive libraries. Prototyping, developing, and shipping are easy with C++ Builder. Start for free at Embarcadero.com. In this episode, we discuss C++ books. Then we talk to Sean Parent and Dave Abrahams from Adobe. Sean and Dave talk to us about restarting the Adobe Software Technology Lab. Welcome to episode 310 of CBPCast, the first podcast for c++ developers by c++ developers i'm your host

rob irving joined by my co-host jason turner jason how you doing today all right rob how you doing doing all right doing all right uh you got anything to talk about today well before we get started i think we should mention that it's possible we'll actually miss an episode we might um yeah so you're about to do a little uh vacationing right yes and uh we're recording two episodes before you head out but uh i currently don't have one you know we don't have one another one you know in advance to put out while you're still gone i might try to see if i can do one on my own or see if i can snag someone to be a co-host but as of this moment we don't have another one planned until you get back i just felt like it was worth mentioning because if one doesn't air we've had such a long streak

now that i feel like people would be like what happened did the universe end you know something like that yeah so if you don't hear an episode from us the next week after this episode airs, we're not dead probably, but we'll be back soon. If that happens, maybe we should just skip three 11 for continuity so that it's actually the number of weeks and just go to.

It'd be more confusing. Okay. Well, at the top of every episode, like to read a piece of feedback uh we got this tweet from robert mcgibbons saying uh and it was directed at you jason saying have y'all done an episode on nix i'm listening to the episode on spac and the two technologies seem to have a lot of overlap and i don't think we have but i think there was another uh listener

who also asked us about nix after we did the SPAC episode. And I had not had a chance to reach out to someone who works on the project, but I did briefly look into it a while ago. Yeah, the name is familiar, vaguely. I don't think it's marketed as a package manager oh if i remember correctly it's if you google nix it's a couple results down but it's listed as nix os okay a reproducible declarative reliable linux os maybe we've maybe yeah maybe it got mentioned we may have talked about it at least amongst ourselves yeah i also just need to point out to robert who sent this tweet that you don't spell y'all with y a apostrophe ll it's y apostrophe a ll says the person living

in north carolina i haven't been here that long but i know that all right well we'd love to hear your thoughts about the show you can always reach out to us on facebook twitter or email us at feedback at cppcast.com and don't forget to leave us a review on itunes or subscribe on youtube joining us today is sean parent sean is a senior principal scientist and software architect for adobe software technology lab sean has been at adobe since 1993 when he joined as a senior engineer working on photoshop and later managed ad Software Technology Lab. In 2009, Sean spent a year at Google working on Chrome OS before returning to Adobe. And from 1988 through 1993, Sean worked at Apple, where he was part of the systems software team that developed the

technologies allowing Apple's successful transition to PowerPC. Sean, welcome back to the show. Hey, thank you. It's good to be here again. So did you work on any of those like dynamic recompilation things that went from 68k to PowerPC? No, the, you know, originally, there was an interpreter that Gary Davidian wrote, and then the dynamic recompilation system was done by mostly Eric Trout. What I worked on was the mixed mode environment, which was basically how you handle transition between 68k and PowerPC seamlessly with kind of neither side aware what was executing in what instruction set well so like being able to call like 68k libraries from the PowerPC application

kind of thing yes as well as 68k applications being able to call into the OS which may or may not be implemented in PowerPC, or a 68K application could register an interrupt handler, which would get executed by the PowerPC interrupts or, you know, all of that to get full compatibility. And it worked, huh? And it worked. Yeah, I even have a patent for that. Oh, okay. That's a completely random aside, but how many patents do you have? I do not have that many. I've got

that one from Apple, and then I've got a couple for XMP, which is a metadata format that Adobe developed that's become a standard metadata format. In general, I'm kind of an anti-patent person, So I try to avoid getting

patents and try to get papers published instead. I'm on board with that. But you've got your virtual background right now. And when you looked over, it looked like you were just looking at your wall of patents. You're like, well, I don't have that many. I don't have that many. Just, you know, there to there. Right. Okay. Well, also joining us today is Dave Abrahams. Dave is a contributor to the C++ Standard, a founding contributor to the Boost C++ Libraries project, end of the BoostCon C++ Now conference,

and was a principal designer of the Swift programming language. He recently spent seven years at Apple, culminating in the creation of the declarative Swift UI framework, worked at Google on Swift for TensorFlow, and is now a principal scientist at Adobe, where he and Sean are rebooting the Software Technology Lab. Dave, welcome to the show. Thanks so much. It's great to be here. We're going to obviously spend a lot of time talking about the Software Technology Lab, but I was just curious about the founding of BoostCon, of C++ Now.

Ah, well, so, you know, I guess what I felt was with Boost, we had created this amazing community of people, people whose work was, you know, inspiring me and, and, uh, and, you know, contributing a lot to the world, but I felt like we needed to connect with each other in a more, in a more interactive way. There were so many people that I wanted to actually work with more face-to-face, and I wanted to do more to build virtual communities and and that's uh you know that's considered good enough for me it's still not you know i i love being here with you guys on video but it's still not the same for me right and uh and so for, collaboration has always been like a really, a really central thing.

And so I always felt that that was missing. And, you know, when I had, I had started my own consulting company that was sort of Boost branded, it was Boost Consulting or we became Boost Pro. And, you know, it seemed like, like nourishing the boost community was an obvious move. Uh, so, so that's how, that's how it started. Um, and it was, we were, we were really lucky to be able to, to do it in Aspen where we set it up, which had been a place, you know, my father was a physicist at the, and he, he, you know, attended the Aspen center for physics on a regular basis. And, you know, I just,

I just saw the kind of work that the physicists were doing there together. You know, there was just all of this like really exciting collaboration going on and i knew it was like that space was where i wanted to have um i wanted to have the boost contributors meet too so that's really cool i was actually going to ask how you picked aspen that makes sense now um cool is it fair to say i actually i'm curious was it fair to say that's the first C++ conference that you're aware of? Because it's the earliest one I'm aware of. I think so.

Well, yeah, I think there were one-offs. Okay. Okay. I remember some large event in Las Vegas, which I don't remember the details of, but I spoke there. I think that was on C++ World. Really? Yeah.

Yeah, I spoke there too. Yeah, it was a one-off. And yeah, so I think C++ Now BoostCon must have been the first repeating conference. That's really cool. Well, thank you for doing that. Yeah, definitely. All right.

Well, we got just a couple news articles to discuss. Sean and Dave, feel free to comment on any of these. Then we'll start talking more about the work you'll be doing at Adobe Software Technology Lab, okay? All right. So this first one is another blog post from Andreas Fertig's blog, who is working on a book programming C++20. And this one is a neat trick with constyvel. Jason, can you tell us about this one? Andreas points out that it's difficult sometimes to guarantee that something has been calculated at compile time,

but consteval guarantees that. And you can use a consteval function, free function, to kind of force a constexpr function to be evaluated at compile time. Very nice. Okay, and then the next thing we have is on cppstories.com, and this one is constexpr dynamic memory allocation in C++20. And, Jason, can you walk us through this one too? It's just an overview of what's possible

with dynamic memory allocation at compile time in C++20 and the fact that you have to free things before constexpr evaluation frame has exited so you can actually use this as a way one of the the things that um by tueme points out here is that you can actually uh use this as a way of checking your code for memory leaks because if you try to evaluate your constexpr function that does memory allocation and a constexpr context, and you fail to free the memory, you have a memory leak. Catch up. Very nice. I wonder how practical that is and got a real world use for detecting leaks. Yeah, I don't know. But it's an interesting

aside. Yeah, yeah. It's also I think, maybe even perhaps more useful. First of all, we all agree, no raw new and deletes. But if you're going to do it, it can actually detect if you did a if you did an array new, and then did a not array delete on that data, then you would get a compile time error. So that's perhaps also an interesting thing. But address sanitizer would catch that also. All right. And then the last thing we have is this GitHub page someone put together, which is CPP books, and it's the comprehensive catalog of C++ books. And it seems like they really went through a whole bunch. They're like cataloging, you know, beginner books, advanced books for C++ developers, you know, what version of the language they might be focusing on. So it does look like it's a pretty comprehensive list.

It's missing elements of programming was the first thing. Now, okay, is it fair to call elements of programming a C++ book or not? Yeah, I think it kind of has to fall in as a C++ book. Okay. It's also missing my book for what it's worth. That's true too. It is a C++ book. It's also missing my book for what it's worth. Which it's not. Well, to be fair, it's missing my book also.

So we need to put in a couple of PRs here. No, wait, sorry. I see on the very bottom. Yours is the very last book on the list. It's template metaprogramming. Okay. God. Not that old. 2004 it says? Yeah. That Not that old.

2004 it says? Yeah. That's pretty old. Does it make you feel old to think that your book is an old and classic book? No, I mean. I didn't mean that. Seriously. No, there are plenty of things that make me feel old, like the advancement of C++ in the last few years, for example.

I know this is a podcast for, by, and about C++ programmers, but I used to be a C++ programmer. Whether I'm still a C++ programmer is maybe a little open to question. There's so much that's happened in the language since I was actively using it. Well, on that topic, I've been kind of curious about your move from C++ to Swift and then your now journey out of working on Swift full-time. So, I mean, you could give us a history if you would like, or I can ask you more detailed questions. But how did you get involved in the Swift project in the first place? Well, I guess so I had been running my own consulting company for a while. And that, you know, as an engineer, you quickly discover your limitations in areas that you haven't been trained for, like marketing, for example.

And I really, you know, got tired of flailing around in that space, trying to do something, not really being sure I knew what I was up to. And there were other aspects that were getting tiring for me. So, so, uh, I decided, you know, it was time to try something else. And so I started looking around for positions and I, I happened to, uh, talk to Doug Gregor at a C++ committee meeting and, and said, you know, does, do you think Apple might have something? So Doug had just finished doing Clang at, you know, C++ Clang at Apple. And, you know, that was a very impressive piece of work. And I thought, you know, maybe there was a role for me over there. And he said, well,

yeah, it might be an okay fit. I don't know. Why don't you come out and do an interview? And so I did. And, yeah, they were, you know, technically supposed to be keeping what this project was a secret, but by the time the interviews were over, I pretty much figured out the basics. Objective-C had somewhat run its course as a useful thing at Apple. There were a lot of problems that they wanted to fix, most notably that you would constantly have to drop down into C or C++ to do something effective,

so you're always bouncing around the language boundary. And that's a problem a lot of systems still have today. So C++ still largely serves that same function for Python programmers. And yeah, so I could tell that they were doing something about a new language. And it was funny. When I accepted, I was talking to Chris Latner on the phone, and he said, so do you want to know what we're working on? I was like, yeah, totally. And, you know, he said, well, we're making a new language to replace Objective-C.

And I'm like, well, I figured that much out. Can you give me anything more? It's like, no, wait until you start. So I had to sort of just, you know, hold my breath for a few months until I could get started. But, you know, for me, new languages come along every week and they die in obscurity. Right. And, you know, we know part of the reason that C++ has been so successful, you know, a big part of it was the fact that it was built on C. Other parts of it, you know, I guess are still a mystery to me in the sense that it kind of

exploded shortly after I went to Apple. Like there was a new explosion, you know, John Kalb's book, The Beast is Back. So, where was I? So, new languages come along every day, but the chance to do one that was actually backed by Apple made it seem a lot more viable. And the chance to do it with this group of people who I had an immense amount of respect for, um, uh, you know, seemed like just too great to pass up. So that's where that's, that's how I got into it. Okay. Very cool. Well, can you tell us a little bit more about what your role was in the development of Swift? I guess it had already started a little bit at the time you got brought on by Apple. Yeah, there wasn't much there.

Okay. They had some ideas. Okay. But, yeah, so my primary responsibility was the standard library. So the whole standard library design, which ends up playing a very important role in a language design in terms of there's this feedback loop that you have to get when you design a language. You have to actually use it so that you have some idea of how well it's working. So it had that very important role. But I also, for example, was responsible for the mutation model. So before I got there, there was no idea of constant, for example.

Yeah, I mean, there were a lot of really basic things were not there. Also, I think aside from C++ and arguably Rust, depending on how you look at it, I think Swift is the first language to really take value semantics seriously. And that was mostly because I fought for it. And it turns out there's like this, you know, I learned a huge amount by doing that.

There's like a different world of trade-offs around value semantics that I now see that wasn't visible to me as a C++ programmer going into the project. Interesting. I'm a little ignorant on Swift. I've never really looked at it. And I'm kind of curious how it compares to C++. Like, was a C++ programmer be able to just step into Swift and be like, this looks familiar? Or is it like Rust with a very different syntax? It's, I think, well, so I think programmers in almost every language have the experience that, oh, this is just like that language I know. In fact, like we had this, you know, we started calling it a Rorschach language because everybody sees the language they're familiar with in it. We had people saying, oh, this is just like Haskell. Oh, this is just like Python.

Oh, this is just like Kotlin. And I think Swift drew liberally from lots of other languages. I think you would find it generally familiar. Of course, there's a lot of superficial stuff in C++ that if you're focused on the superficial surface layer, then you might be surprised because the declaration syntax is like most other modern languages, not this weird inside-out building function types and array types thing. And the defaults are right. So things are mostly immutable unless you say otherwise. So those things are different.

But if you have an idea about what a solid programming system is supposed to be, I think Swift is generally pretty familiar. It's obviously hard for me because I was on the inside as a designer. But my experience is that most people experience it a lot like they experience Python, which is, you know, when I started programming in Python, I was had as a mentor, the great Tim Peters, who wrote the Zen of Python. I don't know if you've ever seen that. Go into Python and type import this and you'll get the Zen of Python. I don't know if you've ever seen that. Go into Python and type import this, and you'll get the Zen of Python. But, you know, Tim said to me, you know, don't worry about learning Python. You already know Python. And that was because, you know, it's just, you know, I mean, the white space indentation thing is weird, right? But it sort of follows what you would think a dynamic programming language would be.

It tries not to be esoteric. And I think Swift does a really good job of avoiding the esoteric also. All right, cool. I wanted to end up the discussion for just a moment to bring you a word from our sponsor, C++ Builder, the IDE of choice to build Windows applications five times faster while writing less code. It supports you through the full development lifecycle

to deliver a single source codebase that you simply recompile and redeploy. Featuring an enhanced Clang-based compiler, Dinkumware STL, and packages like Boost and SDL2 in C++ Builder's Package Manager, and many more. Integrate with continuous build configurations quickly with MSBuild, CMake, and Ninja Support, either as a lone developer or as part of a team. Connect natively to almost 20 databases like MariaDB, Oracle, SQL Server, Postgres, and more with FireDAC's high-speed direct access.

The key value is C++ Builder's frameworks, powerful libraries that do more than other C++ tools. This includes the award-winning VCL framework for high-performance native Windows apps and the powerful FireMonkey framework for cross-platform UIs. Smart developers and agile software teams write better code faster using modern OOP practices and c++ builders robust frameworks and feature-rich ide test drive the latest version at embarcadero.com well i'm sure we could do a whole episode on swift but uh we did you know bring you both on

because uh of the adobe software technology lab and sean i don't think we really talked about this before on the show but can you tell us you know is, how it got started, and how it is getting restarted? Sure. So there was the original software technology lab, which started, I don't know, about 2001, maybe 2002, right in that time frame. And that came about because at Adobe, we had managed to hire Alex Stepanoff, and then he joined one of our shared tech groups, and then he was fairly quickly fired. And I put in a pitch to keep him on board, and the result of that was approval to keep him under the condition that I manage them. And so together we started the Software Technology Lab. And it was somewhat a spin-out from Adobe still has a research team.

At the time, our research team was called our Advanced Technology Group. And I was in ATG, and we brought in Matt Marcus, who was also from ATG, and Paul McJones, who was also from ATG and Paul McJones who was in our ATG group. And then our other member was Foster Brereton who is now one of the senior people on the Photoshop team. And the charter that we settled on for the Software Technology lab was to improve software practice at Adobe, and we're carrying that forward. And we define practice to be a bit distinct from process, meaning that we're not concerned about how you do code reviews or whether or not you're following a scrum model, but we care about what engineers are actually typing when they're at the keyboard,

right? What's the code that they're writing, and how do we affect change in the code that they're writing? And we do that in three key ways. One is through education, which is teaching courses. The course that we were teaching in the previous incantation of the Software Technology Lab led to the book Elements of Programming, which is Alex Stepanov and Paul McJones' book. So that's part of it, is the education bent.

There's a library and tooling side of this, which is where the Adobe Source libraries came from, which are still available in open source, although they haven't been heavily worked on and just been kind of keeping them running for the last decade or so. But they're still in very heavy use at Adobe, and the source libraries themselves, I think, had a fairly significant influence on the direction of C++11 at the time. And then there is a research component, which is collaborating with universities and colleges to try to get traction on some of the bigger, harder problems.

So this time around, what was kind of the catalyst for the restart has been Adobe, I think along with the rest of the industry, struggling to get a good handle on concurrency. And, you know, we're seeing machines with increasing number of cores and they're heterogeneous cores. And we have ML processors and GPUs. And we have, you know, thermal issues where if you overdrive the system, things slow down. And so just the entire programming environment around how do you deal with concurrency, both to get kind of stopwatch performance as well as to improve interactivity,

which is something we're very concerned with in the products. How do you best utilize the machine resources to get those effects and at the same time not create an environment that's fragile and error-prone? And at this point in time, a lot of our defects and certainly the highest category of defects we have climbing in the company are things that amount to issues with concurrent code. And so I made a pitch to say we should restart the software technology lab and we should go see if we can focus on this problem and managed to snag Dave and bring him on board. And so we're just getting things started again. So what years was it originally active for?

I'm curious. So it was 2001 to 2009. So we had an eight-year run the first time around. And then we hit a bit of a political roadblock inside the company. And in a pretty spectacular fashion, the team was disbanded and I resigned. And then Matt had just been laid off, which was part of what caused this whole cascade of events. And at that point, Foster had already moved it back over to the Photoshop team. And Alex and Paul resigned soon after I did. So that was kind of the end of it. I ended up going to Google for a little over a year, then came back.

I'm curious, you reminded me your whole discussion reminded me and I feel like maybe I'm misremembering something but I believe a few years ago you presented your own future implementation at C++ Now, is that correct? That's correct, that's the STLab concurrency library Okay, and I was going to say you did host that with STLab on that GitHub, right?

Yeah, so what happened was kind of after Okay, and I was going to say you did host that with STLab on the GitHub, right? Yeah. So what happened was kind of after Adobe Software Technology Lab fell apart, when I came back to Adobe after being at Google, I had kind of some ongoing fights internally about support for the libraries, and the agreement I managed to cut was that I would take over support so long as I could move it out of Adobe's control, effectively. And so I bought the domain stlab.cc, and that now hosts both the Adobe Source libraries as well as just the STLAB libraries, which includes the concurrency library

that you're talking about. Yeah, and continue to maintain things there. The concurrency library in particular, that was something that started because I was working on Lightroom Web, which is, if you're a Lightroom customer, you can go to lightroom.adobby.com and log in and see all your photos and edit your photos in the browser, and it's a pretty spiffy environment. At the time, we wanted to support asm.js, which was single-threaded, and so had this

heavily-threaded code base, and the challenge was, how do I take this heavily threaded code base and rework it so that it will run single-threaded with good performance as well as scale up to many threads? And what I found was the existing solutions out there didn't scale like that. They required some amount of concurrency and kind of didn't behave as expected. And so I ended up writing my own library, gave a talk on it. In giving the talk, I kind

of cleaned things up enough that I could just stick it in an open source repository and didn't really have a lot of plan to take it further. But then Felix, who's one of my key contributors, he jumped in and he works for a medical instruments company out of Germany. But he found the library useful and started contributing to it

and that kind of gave the whole thing life. And so it's evolved a lot over the last few years. That's right. A couple of years ago, we had Felix on to talk about that concurrency library. I forgot about that.

Yeah. Right, right. Now, you know, I found for myself and for my wife as well that a lot of the interesting things that have happened in our jobs are things that we volunteered for or said, you know what, go to your boss and be like, you know what, I actually want to be doing this completely different thing now. And, or this unexpected thing that you weren't planning to pay someone to work on. And Sean, if you don't mind, it kind of sounds like you've done that a few times in your career that you've been like, you know what, I think this is what we need to be doing next. And you've made interesting career moves that way. that is that fair uh it's somewhat fair um uh you know i i was fortunate enough to kind of work on some really interesting things early on in my career including like you know mixed mode at apple and i worked on

quick drive gx at apple and then i joined adobe working on the photoshop team and so i was like the eighth person to work on photoshop and so i spent a lot of years, working on the Photoshop team, and so I was like the eighth person to work on Photoshop, and so I spent a lot of years working on the Photoshop team. And Photoshop 4 was kind of an interesting story, but it turned into basically a two-person project for Photoshop 4, and that was myself and Mark Hamburg. And it was intended to be a Photoshop 3.5 and kind of a quick dot release

that was needed to generate revenue. And it became something much bigger. And the success of that kind of established my career at Adobe. And so I kind of credit that one pivot point to buy me a lot of freedom. Okay. And yeah, and since then, I've had a fair amount of flexibility, and now a senior principal scientist is a senior director level position,

so I report fairly high up in the hierarchy, and I get a fair amount of autonomy to work on things that I think are interesting and to go solve problems. And I've got a pretty good track record of shipping major projects that have done well. So most recently in the marketplace is Lightroom Mobile. So Lightroom on iPad. That was something that was started with three people for doing the first proof of concept, and I was one of them. And we had to pitch the idea and initially got a no. And so we kind of had to come back and eventually got a yes and went off and did the proof of concept for it. And now it's a successful product. So now that you've managed to get the software technology lab restarted and you have Dave on the team, you said there's going to be a focus on concurrency.

Is there anything specific you can tell us about that you and Dave will be working on? Well, yeah, Dave and I are still sorting through that. But what we do know, I've got this book that it was actually Herb Sutter who suggested I write it after I gave my C++ seasoning talk. So it's the Better Code book, which almost any time I give a talk, they're Better Code something. And so I've got a fair amount of notes for that, plus all the talks, plus a very small start at doing the actual writing for the book. And I've taught a workshop and a course based off of that at Adobe and the workshop recently at ACCU. You know, a fair amount of that is dealing with value semantics, which I think are important

for concurrency, and then as well as dealing with the concurrency issues directly. And so as far as the educational component, I think Dave and I are going to focus on getting that course established and trying to complete the book. So pull that all together. On the library tooling front, at this point, we're still kind of kicking around ideas. There are some shortish term things that I know are needed. Some of them are just kind of an expansion of what we have for the current STLAB concurrency library. but there's just no really good way out there for dealing with platform specific concurrency libraries right on Windows you have Windows thread pool and on Mac

you have GCD and but it would be nice if you could you know and then you have things like Intel TBB and things like that it would be nice if you could, you know, and then you have things like Intel TBB and things like that. It would be nice if you had kind of a library that would span across those. And if you were running on Windows, would be using the Windows thread pool as its underlying primary mechanism. And if you were running on Mac or iOS, it would be using Apple's GCD thread pool and the facilities that are there. And just kind of providing a good common veneer over the top as well as as as portable aspects and some of that's already in the STLAB libraries but there are some key pieces missing still there so so i'd like to flesh flesh those things out to get a get a common api um there are some some common problems that come up again and again that we'd like to tackle.

I mean, there's the obvious ones around kind of memory safety and, you know, proper use of value semantics and how do you deal with that end? And can we provide some kind of tooling to do a better job at catching those things. But there's also some missing gaps, like the once you spin up tasks inside of a thread pool, it becomes very difficult to shut those systems down. How do you actually quit the application? Because you have tasks that are registered within your thread pool which have maybe global dependencies, um, uh, uh, you know, on, on other singletons in your, in your system and global dependencies on other singletons and a multi-threaded environment just does not sound like a good situation.

It doesn't sound like a good situation and it's not a good situation, but it's the reality when you're dealing, you know, with multimillion line code bases that are that are 30 years old and you kind of don't have the the luxury of saying well if we started today how would we write it right that the correct answer has to say if we start from where we are how do we evolve it and and how do we move forward and And so, you know, there are some interesting challenges there in kind of how do you deal with dependency orders at shutdown, your normal scoping orders for global variables as far as like, well, if you want to guarantee the destruction ordering, you want to guarantee the construction ordering.

So if I construct a singleton and I'm going to need another singleton in the destructor, make sure I touch it in the constructor so that it gets initialized first and then will get destructed in the reverse order and everything will come down correctly. But those tricks don't work when you're registering tasks inside of a task system.

You don't have any way to declare those dependency orders. So I've got some ideas on how we can approach that problem, but it's an ongoing pain point, I think. The number of times I see it's not just our applications, but other applications fail to shut down cleanly. Apple Mail like frequently hangs on me trying to shut down cleanly. And, you know, crash on quit is just a big problem. I often ask students who has experienced a crash on shutdown, and almost everyone raises their hand, which I use as an instructor, as a teaching moment to say, stop using singletons. Yeah, and it's like, yes, please stop. But the reality is even your thread pools themselves tend to be singletons and, and,

uh, you know, your heap allocator, right. And delete are, are singletons and, and these things, you know, are there.

And, um, uh, you know, it's just a question of how, how do you deal with them correctly? I even see things like in the, in the crumb code base,

they have a, a do not destruct construct, which technically is undefined behavior, but they wrap it around a class, and then it basically suppresses the destructor from that, from executing, and then they continue to

access it after it should have been executed, and that's where the undefined behavior comes in, because even though they didn't destruct it, as far as the compiler is concerned, that object is dead, and that's UB. And I kind of hate people introducing undefined behavior into their apps to

solve these problems, because eventually that will bite you hard when the compiler becomes smart enough to say, well, you couldn't possibly be accessing it, so I'm going to put something else in that memory slot. Yeah. Right?

Well, Dave, that sounds like a huge change for you, because you have been effectively, it sounds like, in a green field for the last seven years, working on a brand new project where you could define, and now you're going to be working with Sean, helping people who have these 30-year-old codebases with singletons that rely on singletons. Well, yeah. So, I mean, greenfield work, if it's going to matter, is never really greenfield, right? You have users and you have their constraints of the use cases. And, and yeah, I mean, you know, the whole, one of the things I love about programming is that for it to matter, there's like this hard stop against the universe, right? The universe has certain constraints and, and if you don't meet them, your, your stuff doesn't matter, right?

So you have to perform well enough, uh, for example, or you have to be usable. You have to be easy to understand. All of those kinds of things apply. And as soon as we started developing a user base with Swift, that was only a couple of years in to my work there. Then, obviously, we had users we had to answer to, right? Which is, so that's a bit of a pain, you know, having users. But then again, if you want to matter. Crazy, yeah.

So there's that. But, you know, I view, I think, like all of the most important code in the world, broadly speaking, is in C++. And broadly speaking, the, you know, largest community of programmers who need a contribution are programming in C++. And so, you know, I mean, the reason I'm in this ST Lab effort, for one thing, and the reason I went to do Swift is that, you know, I identified my core mission is to make a difference for programmers, is to, you know, sometimes I say to fix programming, but, you know, that's to fix programming by empowering programmers. Right? And as far as I can see,

you know, C++ programmers need a lot of help for a lot of reasons. And, you know, if we're going to make a better future for programming, part of it is going to have to be acknowledging those existing systems and figuring out how to migrate people into a more coherent world

that they can reason about better, that they can, you know, address better, all that stuff. So, yeah, for know, address better, all that stuff. So yeah, for me, it's just on the continuum. Okay. So I was just gonna say, on that note, you know, you want to help out programmers, I realize the software technology lab is just restarting. But you, you know, have contributed to the C++ standard in the past? Do you see yourselves trying to guide the direction of concurrency for C++ in the standards process? I don't know how direct a role I want us to play in that. Adobe now has Jared Wiles,

who represents Adobe on the C++ standards committee, and he's kind of got a dotted line connection with our group here. So there is some relationship there. And some of the things, you know, I don't follow the day-to-days with what's going on with the Standards Committee, but some of the things I've seen in the upcoming concurrency proposals frighten me. So, you know, my somewhat usual role with the Standards Committee is to find the right person and lob a hand grenade at them and

see what happens. So we'll see how... You tried to lob one at me when I got hired, but I said, no, I'm not... I'm not going to pass that hand grenade on. Sorry. Back to you. So, yeah, you know, I suspect we will end up having some influence on the standard itself, either directly or indirectly. And right now we're still at the phase of trying to figure out what do we want to tackle first

and exactly what projects are we going to take on. And the problem is far bigger than two people can tackle. But we're trying to look at what are the pain points for the current applications and get far enough out in front of them that we can kind of blaze a little bit of a trail and say, you know, run this direction and you'll be in less deep weeds than the direction you might be running in. Not out of the weeds. Not out of the weeds, but maybe less deep. I want to add a couple of things just because Sean is maybe making this sound

a little bit more pedestrian than I see it to be. One of the things that Sean has been saying about that concurrency library since I got there is I'm not even really sure it's the right thing. I don't know that we've got the right paradigm for doing this. And, you know, by the way, Sean said I happen to snag Dave, but it's really we've been threatening to hire each other for years. So I'm really glad that it finally happened. Well, he won then, I guess.

Part of the reason that I always wanted to go and work with Sean and also go to work at Adobe is that Sean is always trying to get, you know, get at the essence of, of problems, find some, find some deeper truth than just, you know, this is a neat library interface or, or, you know, look at this trick that I can do with C plus plus. Right. And it, you know, I, I, you know, the fact that I'm the guy that brought value semantics so strongly into Swift is like a lot due to Sean. You know, when Sean started talking about that, you know into production as a way of proving that truth, that this is a place where you're going to get supported in doing that. So that's another reason that I'm really happy to be making this move now.

So out of curiosity, is there any chance that Swift will be working its way into the Adobe code base? I have no idea what the interop between C++ and Swift is, or are you going to be moving into a full-time C++ world again, Dave? I suppose there's a chance of almost anything. I mean, Adobe has a huge C++ code base. And so C++ is not going away at Adobe anytime soon. It's got 30 years of technological investment in this code base. And oh, by the way, another thing I want to say, just because we're talking about the code base,

another thing that really impressed me that made me want to go to Adobe is that Sean told me that they have a target that 60% of the programmer effort should be going into just making things better in the existing code. And yeah, I know. 60%? It does that to me. Wow. You know. Should I get a job there too?

No, I'm just kidding. So this came about, this was actually years ago when I was an engineering manager on Photoshop for a while, back in the early days. And so was Mark Hamburg, and we kind of traded off the role a couple times as to who was managing and who was engineering. You know, and Mark's observation at the time was that it's easier to make a mess than it is to clean it up. Yeah. at the time was that it's easier to make a mess than it is to clean it up. And so if you want your code base to kind of continue to grow and prosper, then something more than half of your effort has to go into cleaning things up. And in the early days, we stuck pretty hard to that rule. And then, you know, at one point, you know, it hasn't always been that way.

I had a manager on Photoshop tell me, hey, he was just increasing the resources to get up to 10% on kind of code maintenance. But in the last few years, we've managed to affect a big pivot with the team and demonstrate that these investments in the code base actually pay dividends. And so after many years of being milked as a product, Photoshop is back on a growth trajectory and the team's growing. And there is a significant investment happening now into cleaning up the universe. And how do we do that?

You know, you just gave me a great idea because, you know, whenever you're in a job interview, a job interview at the end of the interview, the interviewer always asks, now, do you have any questions for me? Right. Your question should be how much time do engineers get to spend proactively making the code better? Yeah. Yeah. And if they don't have an answer for that, maybe you move on to your next interview. Yeah. And it's a, you know, part of it is the management and part of it is cultural. And it's a, you know, part of it is the management and part of it is cultural. And it's always something that I think needs reinforcement, you know, a rule that's kind of never died on the Photoshop team, which is, has always been, if you come across, you know, something that's wrong, like don't file a bug, just fix it. Just roll up your sleeves and fix it. And, you know, it doesn't matter if it's your code.

There is no your code or my code. There's just the code, right? So if it's wrong, just fix it. And, you know, as you bring on new people, right, everybody's like, well, I don't want to touch it, right? Like it's this house of cards and I don't want to touch it right right like it's this house of cards and i don't want to touch it and and it takes kind of constant reinforcement and effort to say to say look you know we have testing we have unit tests your chance of like taking down the universe you know causing everything to collapse is is relatively small right we can always revert whatever it is you're doing um so just roll up your sleeves and and get

it done and you know even if it means i find little things like i'll find a spelling error in a in an identifier and it's like fine so check out 200 files and just go fix that everywhere right right because it just makes it so much easier if you're like oh wait you know it's like how many people have gone over this typing it wrong because they didn't want to or copying and pasting because they just didn't want the pain. It's like the broken windows theory of policing, right? Like if you leave stuff like that around, it lowers the standard for everything. And, you know, I want to say something because at least Sean and I are kind of old fogies here. I want to say something to if there are younger programmers watching this, because, you know,

I consider it, it was a real privilege for me that in my first job, I spent, you know, like 10, 8, 10 years living with my own code. And, and because of that, you know, I was, I was able to both, you know, produce stuff, but also experienced the pain of having done stuff wrong and, and made messes, right? And I think too much, especially when the market for software engineering heats up, you have people that they get on the project, they work on it for a year, and then they're on to the next thing, and they never see that code again you know and um and you can see like you go to the app store uh you know on your phone or whatever you can you can tell that there are a lot of apps out there that are developed that way that that they never got to good quality

and they and they're never going to get there there and and um you know that's from my from my perspective as an engineer it's like that would be really unrewarding you know what i i want to find i want to you know learn something some deep principle about about how to program that's going to make code sustainable and make it make a difference on into the future. So, I mean, naturally with a 30 year old code base, if that's your, your, you know, also the goose that lays the golden eggs, it becomes really important to figure out how to, how to move things forward in a sustainable way. Right. Okay. Well, it's been great having you both on the show today. Thank you so much for telling us what you're up to and, and what,

you know, should be coming out from the software technology lab in the future. Look forward to hearing from you about, you know, what goes on again. Yeah, it was great being here. Great.

I hope we get to talk again. Thanks. Yeah, man. I hope we get to talk again. Thanks. Yeah, definitely. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com.

We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash cppcast. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode is provided by podcastthemes.com.