CppCast - Cross Platform Mobile Telephony

Episode Date: August 27, 2020

Rob and Jason are joined by Dave Hagedorn. They first discuss a blog post from JeanHeyd Meneide on exception free containers. Then they talk to Dave Hagedorn from TextNow about his teams efforts to transition an existing iOS/Android app to using a cross platform C++ library. News Here I Stand, Free - Allocators and an Inclusive STL Awesome hpp Standard library development made easy with C++20 C++ Montreal Meetup Some things C++ does right Links TextNow Enginering Blog TextNow Careers Sponsors PVS-Studio. Write #cppcast in the message field on the download page and get one month license PVS-Studio is now in Compiler Explorer! Free PVS-Studio for Students and Teachers

Episode 262 of CppCast with guest Dave Hagedorn recorded August 26, 2020. Sponsor of this episode of CppCast is the PVS Studio team. The team promotes regular usage of static code analysis and the PVS Studio static analysis tool. In this episode, we discussed exception-free containers. Then we talked to Dave Hagedorn from TextNow. Dave talks to us about his work integrating a cross-platform C++ library by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? I'm okay, Rob. How are you doing?

Doing okay. Any news with you? I know you've been looking at, you know, changes with travel restrictions and everything. Anything to share with that? Yeah, so my training that we had been talking about for the last several months in Stuttgart for the end of September, beginning of Octoberober time frame uh is officially canceled now uh but i mean that's just looking it seems highly unlikely that us will be allowed into shengen area into the european passport zone uh anytime soon so yeah that's been canceled right that's unfortunate hopefully you can do the same type of training next year though right yeah we are gonna keep our ear to the ground

see what happens and you know when travel things start to open back up again make plans again awesome okay well at the top of the episode i'd like your piece of feedback uh we got this tweet from connor hoekstra who we had on the show uh maybe two years ago a long time ago at this point yeah so he says on the most recent cpp cast uh rob mentioned some podcasts take the summer off and jason asked why don't we do that and i replied maybe we should uh retweet this or comment to show our love for cpp cast and then it has a lovely picture of two kittens hugging saying we love you cpp cast please don't leave us and yeah we were just joking about taking the summer off i don't think uh either of us really need a break although yeah it gets busy sometimes

but yeah i think we're planning on taking at the moment no plans to and i think we both kind of feel like man we've had such a long streak of not missing an episode that we don't really want to miss an episode either. Yeah. Yeah. Oftentimes, you know, we miss like two to four episodes a year, but we haven't missed a single one yet. Knock on wood. No conferences and no travel. Right.

Yes. Hopefully we'll keep that streak going this year. Yeah. Okay. Well, we'd love to hear your thoughts about the show. You can always reach out to us on Facebook, Twitter emails at feedback at speakcast.com and don't forget to leave us a review on itunes or subscribe on youtube joining us today is dave hagedorn dave is a technical manager with text now located in waterloo ontario canada he leads the client calling team at text

now the leading mobile app offering affordable cell and wi-Fi-enabled phone service. Dave has over 13 years experience writing mobile and embedded software and tools in C, C++, Java, Kotlin, Swift, TypeScript, and Python. Dave started his career at BlackBerry Research in Motion doing embedded C and C++ development and representing BlackBerry at the NFC Forum and GSM Association.

He went on to work at a local startup where he did embedded development and wrote cross-platform C++ for Android and iOS. Dave has a bachelor's in applied science and computer engineering from the University of Waterloo. He enjoys cycling, running, powerlifting, woodworking, and curling. Dave, welcome to the show. Hey, I'm really glad to be here. Really like your show, and yeah, just glad to be on it.

Awesome. Thanks for coming on. Good to have you. You know, you say powerlifting and curling, and you don't mean like curling weights in this case. We're talking about brooms on ice, right? Yeah, yeah, yeah, yeah. Yeah, two separate sports. Yeah. be factoid for our regular listeners is i almost never read the bio before rob does so i'm always just like you know sometimes it's pasted in just a few moments even before we actually start the interview but as i was reading uh 13 years experience with embedded devices my brain immediately said okay what was happening 13 years ago what projects would he have been working on

and then i saw that you said you got your start at blackberry not a whole lot of blackberry development going on these days no i don't i don't follow it too closely anymore but i i think they're still branded phones i think i think somebody somebody picked up the rights to brand the phones again who's going to start manufacturing them but blackberry themselves is not really in the phone business that I know of. What was the operating system like when you were developing? What was that? I don't know anything about it. It was many. So BlackBerry had their own homegrown OS early on,

which was a combination of like a core kind of embedded real-time OS that BlackBerry developed. And then on top of that, they had like a JVM and like a Java runtime that you wrote the apps in. Right, Okay. So I wrote up the core embedded layer, right? So pure C. And then later, so that was up until what they called BlackBerry 7, like the BlackBerry 7 OS.

And then BlackBerry made this jump to what they call BlackBerry 10, which was when they moved to QNX or QNX is an operating system. So BlackBerry bought QNX and incorporated that into their OS. And that was their real big push into making a really modern smartphone to compete with iOS and Android at the time. So that was kind of cool. We got to work on C++ a bit at that point

because QNX had a proper C++. They used GCC, so you could write C++ on QNX if you wanted to. And then at the end end they just kind of they capitulated and went to uh went to android like everybody else right so i worked on the first android phone um before i left so i got to see that go out the door which was kind of cool it seems like an interesting continuity uh you know some sort of c based operating system with

a jvm on top of it though really right i, right? I don't know. It feels similar. It's funny how everything kind of goes in circles in tech, right? Right. Yeah, at a high level, it's not that different than what Android is today, right? I mean, if you think about it, yeah. Yeah, it makes me think. I don't think we've had anyone on the show ever talk about the Nokia feature phone days when there was some sort of

java applet gaming thing that was possible on those devices on the old candy bar phones too right right yeah outlets were huge back in the day i think for yeah stuff like that yeah okay dave uh so we got a couple news articles to discuss uh Feel free to comment on any of these and then we'll start talking more about the work you're doing in text now, okay? Yeah, sounds good. Okay, so this first one I have is a post from Jean-Huidh Manid's blog and this is

Here I Stand, Free Allocators and an Inclusive STL. And it's a pretty long post, but this is going over Jean-Huidh's efforts to show how you can make std vector and other c++ standard library containers uh exception free yeah yeah what was your take on this one jason oh no it sounds like i mean i i've been kind of deep into some allocator stuff myself lately which will show up in a couple of C++ weekly episodes that are ready to come out. So I read this with interest.

And yeah, as far as I can tell, he's completely right. It would take a relatively small change to the standard library to just allow you to specify exception-free allocators to your standard containers and let them magically become exception-free containers. As far as I can tell tell it's all there i agree it looks it's a good article yeah and one of the things he talks about you know about you know an inclusive stl is that this is kind of one of the major complaints with uh you know game developers that they would like to use the allocators or the uh containers but they don't want to have to deal

with exceptions yeah and but although it does look like it might require an ABI breakage on Visual Studio's standpoint, but that's an implementation problem or detail, I guess, with Visual Studio. Right. Dave, you have any thoughts on this one? Yeah, I mean, I like the idea as well. Like, I don't think many people probably check for, like, std battle lock when they're using vector and stuff like that.

So, you know, I think, I'm not sure if sure if if like stood terminate is always the right decision like i think you'd want the ability to hook that in your own for your own needs right depending on your environment but yeah i do like the idea right yeah it's kind of cool also i didn't know you could sorry i didn't know you could declare a function pointer as no except i thought that was kind of cool yeah and then well yeah he does a reinterpret cast for some extra damage there but just to work around an issue yeah yeah it's like yeah i've never never had to do that i guess but yeah interesting interesting corner case in the language right i was and um for those of you who were like paying attention when I was hacking on the Doom engine, it's interesting that we're in this world where we're like, well, it's, you know, we basically consider it impossible to deal with for additional resources like sound effects. And if it couldn't, then it would do things like free the older sound effects from its least recently used list so that it could allocate memory so it could load in the next thing for the next level.

Like applications at least used to do that as a normal part of programming. Yeah, I guess the easiest is just assume that if you're running out of memory you're really in bad trouble since you have more available there's also the operating system detail like on linux i could i can call malik uh 32 gigs on my laptop that doesn't have anywhere near that space available and linux will return instantly It's not until you actually try to write to that memory location and it tries to allocate the pages, do things go wrong. And that's now it's, that's, we're already past C++ at that point. It's impossible for me to deal with that without using a, um, uh, operating system signal handling or something like that. Okay. Next thing we have is, uh is this list on GitHub, awesome HPP,

which is a curated list of awesome header only C++ libraries. And I like this just because it's very well organized, like there's a table of contents of all the different categories of libraries that are appearing in the list. So you can find almost anything in here. I like that it puts how many github stars each thing has too because that gives you a high level idea of how used the library is right that's a really good point so you can just you know pick your category go look at all the options and have a good idea of which one might be kind of the most mature or most popular at least i uh i was kind of curious why they focus on header-only libraries.

I know those are convenient, but there's also drawbacks to using header-only libraries, right? So they're kind of biasing your choice of frameworks to picking header-only libraries, which isn't always the right decision. I think this is maybe meant as a direct corollary to another library that's managed by a different person called awesome cpp which is in general a bunch of awesome c++ libraries um maybe i don't

know if that was intentional that's how i looked at it anyhow when i saw it right okay yeah that makes sense yeah yeah there were definitely some really cool some really cool libraries there but there's one where they let you get the name of an enum at compile time, like the string value of an enum. Ooh, what is that? Better enum? Magic enum? Yeah, it's called nameof. So they do this trick where they instantiate a template function that takes an enum value as one of the template parameters,

and then they use that pretty function macro to get the name of the function, which includes the enum name, because it's part of the template, and then they hack that string to get the actual... It makes me really want compile-time reflection to get here today and not in 23 or 26 or whenever it lands.

Right. Oh, the this looks... I had to click on the library since you mentioned it, though. I mean, it's got broad support. Clang 5 or greater, which at this point is pretty darn old. GCC 7 or greater for parts of it. GCC 9, that's a little bit new. And Visual Studio 2017. I mean, most projects I'm working on are at least in this ballpark.

Could save a lot of effort. I do wonder what it means for compile time, because I was looking at the implementation, and they don't know where your num starts or stops, like in terms of values. So they do like a compile time, like I think they use integer sequence to instantiate

this template function like 200 times or whatever to cover all possible num values in your num and then i guess they probably pick the ones that actually have a like a name in them right so not probably not great for compile time but but really really interesting that's really fascinating actually okay uh next thing we have is a blog post from Quarantine we've had on the show before. And this is standard library development made easy with C++20. And there's another interesting blog post where he's basically showing how you could rewrite parts of the standard library.

In this case, he's going over std tuple and std pair. And if you use c++ 20 you could really reduce the amount of code necessary uh to write that out but of course then it wouldn't support earlier versions of c++ then the main thing that caught my eye and i still need to come back to in this article to spend a little bit of time with is the use of c++ 20s no unique address um uh attribute which i don't really i admit i don't really understand how it's used C++20 is no unique address attribute, which I admit I don't really understand how it's used. Yeah, not too familiar with that myself.

Do you have any thoughts on this one, Dave? I kind of align with some of the comments in the article on backwards compatibility. I think it makes things hard in C++ sometimes, right? So especially if it's making it hard to maintain the standard library or to add new features to the standard library, I would fully support, you know, okay, if I'm using C++ 20, I'm using a C++ 20

version of the standard library, right? That's not backwards compatible, right? I think that would be a good thing. Yeah. Okay, and then the last thing I have, I actually got this tweet from the the vancouver c++ user group that they're going to be having a canada-wide virtual meetup on september 1st and this one is going to be uh hosted by patrice roy or patrice roy will be uh the speaker for this

event and it's something c++ does right uh so if you're in canada and you're missing your user groups uh definitely go check this out. 1st of September. Have you been attending? Yeah, I was just going to say, Dave, are you a member of either of these Canadian user groups? Actually, no, I'm not.

But I think I'll have to go look that up now. Okay. Well, can you start by telling us a little bit more about what TextNow is and what you've been working on? Yeah, for sure. So TextNow, basically our mission as a company is to provide excellent phone service for free

or as close to free as possible. So with that goal in mind, we provide two products. We have a free app, which is in the App Store and the Play Store. And if you sign up for that, we give you a 10 digit phone number uh for free and you can make unlimited calls and texts um you know over wi-fi right and that that app is it's ad supported okay and then we have a second product which i'm really excited

about so this is in the u.s uh we call it our free nationwide talk and text plan and this with this we actually give you a free a free phone plan right so you can make unlimited calls and texts to the us and canada it's on the sprint network and it's totally free yeah very interesting so is this also an ad supported thing then it is yeah like everything works through the the text now app right which is is ad supported um and then you know with with those products we offer paid add-ons right so we offer data plans we offer international calling um other types of products you might want in the calling space all right and this is uh available on both android and iphone uh yeah yeah play store app store and

then we also have a like a web app as well so if you go to textnow.com and sign up or sign into your account, you're taken to a landing page where you can make calls or make texts or receive calls or receive texts. Okay. This is handy for people. If you're at your desk all day, you can have this open in another tab as your phone or as a second phone line or whatever you need to do phone calls or texting for okay so you know you have all this history in embedded c++ development going back to the blackberry days so what sort of uh you know app does this look like is it a c++ app on both android and ios is it a cross-platform right so the apps themselves are um like we have our android app on our ios app those are our two separate code bases right so our android app's written in java and kotlin and our ios app is written in objective c and we're moving to swift

of course like everybody else um but uh where i work is i work on the client calling team within the techs now. So we're responsible for the calling solution or the calling stack, whatever you want to call it, that these applications use. And what we've been developing over the past year and what we're moving to now is a new cross-platform calling stack that we use in both of our apps. And that's what we're writing in C++. So this is the server-side thing, if I'm hearing you right.

Actually, this is the client-side framework. So TextNow does run their own calling infrastructure in the back end as well, which is one of the really cool things about TextNow. It's how we can have really good phone service when we control both ends of the phone call. But there is a client-side piece, right, about how do we talk to calling infrastructure, right?

And that's what we maintain. It's like a library that the rest of our apps import that has a calling API, right? So the ability to make a call, receive a call, all the things you would do with a phone call. So, all right, then, just to make sure I understand, this is a C++ library that will be used on both the Android and the Apple device? Yeah, yeah.

Okay. Yeah, so we're at the point now where actually almost all of our Android users are moved over to this new library, and we've seen really positive results, actually. So users can opt in to give us feedback through in-app surveys and stuff. And just through comments we've seen in the app store as well. We've seen general improvements across the board. So that's really exciting. So you said the Android app is moving or is finishing up moving towards the new library, what is it replacing?

Did you just have a whole bunch of Java and Objective-C code that was handling the old calling stack? Pretty much, yeah. At a high level, more or less. On Android, it was Java code wrapping an open source calling framework. If you know calling at all all there's a protocol called sip which is session initiation protocol right so we had incorporated and some open source framework into android with yeah java wrappers around it and something similar on ios and but yeah it was

two fully separate code bases uh two different languages um and you know it's worked well for for like a long time now and for our customers, but when we're looking forward to how we wanted to use, where we wanted to take calling in the future, right? And we wanted to incorporate WebRTC and just how can we make calling better and iterate faster? We really wanted to go to one code base, right?

In some common language. Okay. And can you maybe tell us a little bit more about SIP and WebRTC and what some of the advantages are of WebRTC? Yeah, yeah, for sure. So WebRTC is, I guess you could call it a framework for real-time communication, or that's what they call it. But it's basically a library for doing like real-time audio video communication, right? So where you usually see it is it's actually in all modern browsers today um and there's there's a set of um javascript apis that that all browsers

i think all modern browsers support that you interact with with this webrtc library right um so anytime you see any kind of you know video chat type solution like on a web page somewhere or a website that's pretty much always web rtc right um there's a few exceptions but i think pretty much everyone's using web rtc nowadays and it's it's an open source project it's managed by google um so they you know typically it's just incorporated into browsers by browser vendors i guess right so firefox or chrome or edge but you can also take this you know web rtc code base and build it yourself and use it in like an android application or an ios application or wherever you want to use it um but yeah basically its goal is just high quality audio and video so you know it's adaptive to like changing network conditions. It has really good echo cancellation and silence detection and all these types of

things that you want in when you're doing video chat or when you're doing a phone call. So that's kind of the goal of WebRTC. I mean, I can definitely go into more detail, but that's WebRTC at a high level. SIP is all about call signaling. So WebRTC doesn't really define how you manage a call. It really just defines how two peers will set up a media stream to send audio or video to each other. It doesn't dictate how you share the initial info that two clients need to fight each other and connect. Or how you do things like update call status. Typically with a phone call, you've got the phone is ringing, the user's answering, those types of things, right?

Or hold, conference calling, all these things. Those are all done outside of WebRTC. So you need a framework or a protocol for doing that. And what's often used in the telephony world is SIP, which is just a protocol that basically covers all the cases you would ever need to cover in calling. So how you initiate a call, how you answer a call, how you hold a call, all these things.

So are you also using some SIP library that gives you those things or is that that's not built into webrtc it sounds like yeah it's funny it's yeah outside of webrtc and yeah we've pulled in a a um a c library for sip it's open source it's called osip okay yeah and we've pulled that in and they're using that for i guess you could call it like our call signaling layer. And then the other kind of cool thing that we're doing is SIP traditionally runs over UDP. I don't know why, because it's not like video or audio. It makes sense, right? Because you don't want to use TCP for those typically because it has too much latency.

And if you drop a few packets, it's real-time audio, so it doesn't really matter. But SIP is over UDP as well, traditionally, which has application-level retries built into the protocol and all these things that actually kind of get in the way sometimes. So we do SIP over TCP. We actually use a protocol called WebSocket over TCP. And that just gives us... We don't have the headaches of UDP and retries and all that kind of stuff at the application layer. And it just makes the communication more reliable.

Just let the operating system handle that for you, basically. Yeah, yeah, yeah. Did you have to modify the SIP code to work that way? No, actually. So the library we're using is fairly well extractedextracted. It doesn't take care of the sending or receiving. It just provides stubs that you fill in. So you can plug in whatever communication layer you want. So then we use another open-source WebSocket library to do that piece. And then the only other thing I'll say is we also use WebRTC in our web app.

So again, if you go to textnow.com, that's using the browser WebRTC APIs. And that's the one that's already built into the browser? Yeah, yeah. Okay. So does that mean you have a cross-platform app across iOS, Android, and the web? Or is it a little bit different on the web still? It's different on the web. So on the web, it's just pure JavaScript code

interacting with the WebRTC JavaScript APIs. Any plan to move to the C++ compiled to JavaScript? Yeah, we've talked about it. I think we've talked about it in fun, kind of, right? Like, oh, can we use any of our C++ code? Like our business logic, say, right? Around call management, can we reuse any of our C++ code? Like our business logic, say, right? Around call management. Can we compile that to WebAssembly and use that in our web app? But no, we don't currently have any plans to do that. If it makes sense one day, and if it makes

the call-in experience better on the web for our customers, then sure. But yeah, where we are today is fine. So there's no need to do that. So I'm curious how long this process has been ongoing of moving from the Java and Objective-C world to the shared C++ library. Yeah, I would say around a year or maybe just over a year. Right. So we, yeah, it's all kind of a blur now, but no one knows what's happened in the last six months. So I guess it's fair. Yeah. isn't typically how you use WebRTC, even in mobile. But we really wanted to do that because we wanted to use C++ and have a common language for everything, right? So we had to figure out a way to build WebRTC and incorporate that into our C++ library.

So is WebRTC a pure C library usually? It's interesting. So the whole thing is built in C++. Okay. And then it does offer like a core C++ API. But, you know, that's usually wrapped by JavaScript in the browser or on Android or iOS. The project provides Java bindings

and Objective-C bindings, right? But again, that gets you back to like a two-code-based solution because now you're going to have Swift or probably Kotlin code controlling your WebRTC, and then you'd have to abstract that back to your common code somehow. Not really great.

We had to figure out how to modify the WebRTC build process to expose the C++ APIs. And then the other really interesting thing we do is usually WebRTC is built as a shared library that you load at runtime and you call through JNI in Java or what have you, right? We actually build it as a static library and then link that into our overall library, which we provide to the rest of our app. And that's just to cut down on the number of libraries the app

has to load at runtime for startup reasons. And also also it shrinks the webrtc binary i think quite a bit right because it's a really large library it's like six or seven megs when it's all compiled um so if you know if you can link it statically and let the linker do garbage collection and throw away the stuff you don't call into we probably save you know from the stats i've, close to a meg of space, right? So that's significant. So I assume the assumption, presumption, is that you will, in fact, save engineer time and development hours moving forward

after investing the effort in this new project. That's the goal, yeah, is that if you want to change something in calling or add a new feature to calling with our legacy codebases, you'd have to do it twice. It's two changes, it's two pull requests, it's two repos, so two sets of reviewers. It really duplicates the effort in a lot of ways. And like I said, these, I guess I'll call them legacy codebases, have worked well for

us. But yeah, if you can have a common codebase, it just really helps a lot. And we're starting to see that, right? So, you know, we're an agile company at TextNow, which is kind of cool. So we do weekly releases, right? And so we're releasing a new version of our calling SDK to our internal teams, our Android and iOS teams every week. And at this point, it's usually just a rebuild and a version bump in the app that pulls down the new library. And there's not really any API changes required at the interface level between the app and our calling SDK.

So we're able to keep a lot of our changes within our calling SDK where we make them once. How much thinner have the iOS and Android code bases gotten as you've integrated this cross-platform SDK? I mean, it sounds like this library is kind of responsible for a lot of what the app does. Yeah, that would actually be hard to quantify. I don't really know the numbers very well. I do know that at a high level, there is a lot of legacy Objective-C code in our iOS app around calling. And same on our Android app. There's a lot of legacy Java code that gets sprinkled throughout the app over time. Like any large code base, separations of concern kind of break down and, and, and modularization

breaks down. So we've been able to push a lot of calling logic down into like this common C++ code. So I do expect that going forward, we'll be able to go back and remove a lot of that, that like Java or Objective-C code. Okay okay do you have some way uh from the c++ library to say this is the list of options for making a call or something like that so that you can when you make the changes from the c++ library you effectively push those changes out automatically to the to the guis do you know i'm trying to ask here? Yeah. Like the GUI asks the C++ library, so can you give me the list of features here? And then the GUI knows what to render is what I'm going for.

So you mean like does this call support conferencing or something like that? And then the GUI would render like a conferencing button? Yeah, like I'm just curious how you keep the GUI and your library in sync does the does the library push things does the gui ask for things or is you just have to have communication between the members on the teams i see yeah yeah um uh just you know close close communication between the teams i would say i mean we do provide like a calling api to API to our apps, right? So if you change the API, the app won't compile,

which I guess is one way of doing it. Oh, yeah, absolutely. I'm not going to argue with that. But yeah, I don't think I get what you're saying, no. Okay, curious. Today's sponsor is the PVS Studio team. The company develops the PVS Studio Static Code Analyzer designed to detect errors in the code of programs Cheers. However, for C++ programmers, it will be much more interesting to find out that now you can experiment with the analyzer in online mode on the godbolt.org website. The project is called Compiler Explorer and lets you easily try various compilers and code analyzers.

This is an indispensable tool for studying the capabilities of compilers. Besides that, it's a handy assistant when it comes to demonstration of code examples. You'll find all the links in the description of this episode. So you talked a little bit about how when you're given WebRTC, you typically are given the Java and bindings for Objective-C. I'm guessing you're now having to generate your own bindings around your library, which is using WebRTC. What are you using to do that? Yeah, so we use a cool tool called Genie,

D-J-I-N-I, which is from Dropbox. Right. Yeah. I think it's been mentioned on your show before, actually. Yeah, it has. But yeah, it's been a long time. It's been a while. And yeah, and Dropbox, I don't think,

is supporting it anymore, right? Yeah, they've walked away from it. That's okay. What it does is it probably won't need to change for a long time. It's something we could always swap out if we had to. But yeah, what it does is it provides a way of defining your interfaces between C++ and Java or Objective-C. So it starts with an interface definition file, like an ideal type file, where you define all your interfaces and your other types and who implements them,

whether they're implemented in C++ or whether they're implemented in Java or Objective-C. And then it provides wrappers or proxies for those in the other language. So if that makes sense, it just provides a way of defining who implements what and then allowing you to call into that. And it's a really good framework, actually. I really like it. I like that it's IDL based. So if you change a definition and you rebuild all your, your auto-generated

source code, um, you know, all of, all of the code that consumes that, that definition now has to update to, to use the new definition. Right. So you get, if you change something, you get a break at compile time, not runtime. And this is the industry standard IDL you're talking about, right? Um, yeah, I don't think so i just i just call it ideal um oh okay yeah no i just had flashbacks to like the late 90s and uh uh rpc that used some industry standard idl and uh i don't know yeah like soap and that kind of thing yeah yeah yeah no this just generates i yeah, it's its own little language. Okay.

Yeah, it works well. Cool. Yeah, it maps, you know, it has this kind of union of types that work across all languages, right? So like a std vector is an ArrayList in Java, is an SArray in Objective-C, that kind of thing. It also manages memory really well, right?

So if you're pointing to a Java object that implements some interface you know you hold that reference to a shared pointer right so once all your shared pointers that point to it go out of scope then then the garbage collector can go feed that java object stuff like nice it's really neat how it works um yeah i mean i could go into way more detail but it you know short version is it works very well that sounds very convenient yeah yeah yeah and i guess while you know since we talked about Dropbox and Ginny, while you were working on this, I think the big blog post came out that Dropbox was unfortunately abandoning

their support and their own cross-platform efforts. But I'm assuming you're pretty happy with the decision your team made. We are. Yeah, I mean, some of the reasons in the Dropbox post, I think it's fair to say are challenges we don't face. And so they had issues with keeping their builds in sync, like with Xcode and generated code, or just code you build on Android and then build again on iOS. That's not really a problem we have,

because we use a different build system we use basil um which natively supports submitting um or just while building code for ios right so um you know we're able to wrap all that logic in basil basically and just say basil go build go build all this code for ios and then it does right so as we change our our genie definitions or any other code for that matter, Bazel can just pick all that up. Or how we've used Bazel, it can pick all that up and just rebuild stuff for iOS. And then I guess the other

point is we're not really coding GUIs and application level logic so much. We're coding business logic and call control and stuff like that. So whatever language you do that in, it's not going to be that challenging, I don't think. I mean, don't get me wrong, it's still a hard problem.

You still have corner cases and race conditions and all that. Calling is unbelievably complex, but it's a problem you can solve in any language. The C++ group that's working on this shared library, was it pulled from people from the other groups or uh is it a new group that was created with greenfield like um both so you know there was there was there has been a calling team at text now for a while um and part of the reason i got

hired at text now was to uh to help with this effort because i've done this before at a previous job i did something very similar actually with genie and with cross-platform oh okay um and i guess i guess that was appealing to the person hiring me so um so but yeah we also there were also people on the team at the time that they knew c++ and and wanted to to build a cross-platform calling sdk and we're fine to use c++ to do it. Okay, yeah, I was curious. I mean, you pretty much already answered this. If there was like a training or an issue

in getting the rest of the team on board with this or however. Yeah, no, the team actually wanted to use C++ at the time. Like we talked about a couple other languages and there's other solutions out there. But, you know, we wanted to use C++ for a variety of reasons. One was to use the common C++ WebRTC API. And then there's also other frameworks we pull in, like we pull in Google's gRPC framework for talking to our backend.

And that, if you're using gRPC with Pr protobuf version 3, I think that's only supported in C++ right now. Interesting. In the terms of the cross-platform language space. So there were a few reasons for that. And yeah, since that we've grown the team a bit, we've hired one person that knows C++ really well. And we've also had people that program in Java or Kotlin work on C++, and it hasn't really been a problem. Awesome. Yeah. So I guess you could say we're a cross-functional team.

Is the library you work on using the latest version of C++? Are you using, you know, 11, 14, 17? Almost. So we had C++ 20 turned on using 11, 14, 17? Almost. So we had C++ 20 turned on. Oh, wow. And then we actually had to turn it off because we upgraded a version. We upgraded the version of

gRPC we used, which was fine. Or actually, no, sorry. That had nothing to do with it. We upgraded our iOS toolchain. So our Xcode toolchain. And in that version of the C++ standard library, they changed one of the enums. In C++20, it's now an enum class and not a regular enum.

It's a std memory order. Okay. And that broke our ability to compile CRPC code because it does some weird things somewhere casting the enum. So we had to go back to C++17 for that. But we do, we have pulled in, we do use designated initializers quite a bit, because those are supported already

as an extension incline. And then we also use ranges, we've pulled that in. The ranges v3lib. So we're using the algorithms today. We're not really using the views much in our code base, except maybe a few unit tests kind of for fun.

Okay. But more just the algorithms so we don't have to, you know, pass begin and end everywhere. Right. And we've looked at std source location as well, right? Because you can actually implement that in Client 9. It has the compiler built-ins regardless of what version you're on. Okay.

So we looked at maybe using that in our... We have an internal login framework we use for application logging. We thought about maybe using that there, but we haven't yet. I've been really looking forward to when I see official support for that from one of the compilers so I can you know make an episode about it basically yeah you can you can roll your own implementation today like you can use the client built-ins and it does work like it's not right yeah it's not too bad so it sounds like you're using clang on both platforms then yeah almost certainly right yeah so the android mbk for a long time now has

kind of standardized on clang yeah and then uh same with the Xcode toolchain. They've been using Klein for a long time now. Apple uses their own build of Klein, which has kind of some secret stuff mixed in sometimes, which can cause problems. But yeah, it's pretty much Klein everywhere. And then we also use Klein.

We also build our code for desktop, which lets us do a lot of development without having to load an app on a mobile device right so we can just iterate that much quicker and we use client there as well so yeah client everywhere so you said you were you had turned on the c++20 flag and then had to turn it off again but you also said that you are using designated initializers which i know is supported as an extension on the compilers just curious if you had if there's anything else that you had you know had momentum moving towards

c++ 20 that you had to roll back because of that change no we got we got lucky on that one okay yeah nothing yeah nothing no extensive concept support or anything like that yeah well we're actually we're still on at the time and we haven't well, we're actually still on, at the time, and we haven't really bothered to update, we were still on Client 8, which I don't think has a lot of good... Oh, no. Yeah, yeah. But I'm very much looking forward to concepts and really looking forward to modules.

But I think modules is probably a year away by the time build systems pick it up and by the time Bazel picks it up and integrates it. So I don't know. I'm kind of sad because there's a certain amount of developer fatigue that goes with editing your header file and then editing your CC file over and over.

If we could stop doing that, that's really all I want modules for. I'd be so happy. Killer feature of algorithms is just to not be able to pass begin and end, and killer feature of modules is less header file fatigue. Yeah, yeah. Basically, how can we use modern C++ to write code faster? You know, I want to move in that direction.

Right. So you already mentioned that Apple kind of uses their own secret sauce version of Clang that's difficult to tell what version it is, but it sounds like you're approximately on Clang 9 on both platforms, something like that? Probably, I would say. Okay.

Yeah, it's hard to say because we haven't, outside of those few features that I mentioned, we haven't ventured too far forward into C++ 20. So we don't really get to see what breaks when you try to build it on iOS. But probably, yeah. As a company, we usually stay current with the latest version of Xcode. So whatever version of Client that pulls in will be very recent. We've had a lot of discussion on the show lately, which since you said you're a listener,

about ABI breakage, but it sounds like you're not relying on any binary blobs where this would be a problem for you. I don't think so, no. Like we build WebRTC from source and we build all of our code from source and then we link it all together. And we know that when we build WebRTC and when we build our code,

we're using the same version of the standard library. So as far as I know, we're okay there. It gets a little tricky because when you build WebRTC, it's its whole own entire repo and build system. And they have all their own entry dependencies. They have their own entry libc++ and their own entry lib-boringssl for SSL, and lib-grpc and all this stuff. And we have all those same libraries in our code base, right? We use SSL.

We want to make sure our phone calls are secure. But we've done our homework to make sure that the versions that both link in at build time end up in the final binary and are compatible. Right. Yeah. I just did a recent Twitter poll. How many copies of Zlib are linked into your current project? And I think five was the highest number that came back because of stuff like that. Yeah, yeah.

Well, that's every, you know, every shared library your app pulls in, especially on Android, because the default there is to link in Libc++ statically into your shared library or whatever you're building, right? Yeah, it does cause a lot of duplication. Yeah. Which is, again, why we're trying to link everything as one giant library

for our apps to consume for that reason. I understand that, yeah. Other projects I've worked on have moved in a similar direction for similar reasons. Right. It's a really interesting kind of challenging problem, but yeah, it's worth it. You mentioned they use Bazel as a build system a couple times. We have not done an episode on Bazel yet, and anyone listening from Google who would like to do an episode with us,

please reach out. But would you tell us a little bit about uh your use of basil uh does it work well for ios and android projects yeah i mean the short answer is it's it's working really well for us um i mean what i guess the goals of basil as a build system are to be fast and correct um and then that sounds good multi-language as well. Also, I'd say it's really extensible. We're able to use it to build all of our C++ code. All of our Gini code or generated code

is Objective-C and Java. We can build all that. We can build all of our Kotlin code. The one exception is we don't build our Swift code in Bazel. We could, but it's just it's much easier to work with Swift in Xcode where you have code completion and all that kind of stuff So you use Bazel to produce the calling SDK

and then the app team uses just native Xcode? Kind of, so we use Bazel on Android, yes, everything's built through Bazel, and we provide an Android archive, like a.AR file that goes up to our Android team. And that has all the Kotlin bindings to our calling API and everything else that we need. On iOS, we build everything up to the Genie layer, which is the top-level Objective-C wrappings

around our calling API. And in Bazel, we can build that as a static Objective-C framework, I think it's called. And then in Xcode, we link that into our, we have a Swift project, which provides like nice Swift bindings over top of all of our genie code. And plus all of our, like there's There's a bunch of platform-specific support code that we need as well for our calling framework, like audio management, detecting network changes, that type of stuff.

So that's all in a separate Swift project that is an Xcode, and then we link everything together there and give that as a framework up to our iOS team. And this whole process works well with a continuous build environment you have set up? It works really well.

It took a while to get Bazel to play nice in a CI environment. Really? It seems like that would be the... I don't know. I'm just surprised because... Yeah, so it works. But if you want it to work fast, that was the challenge we had. So Bazel does

really extensive caching of all of its intermediate build files and everything, basically. You can cache all that stuff remotely, but it also caches it locally on the local file system. It wasn't

really well documented early on in the Bazel days how that all worked and where this file system cache is and how it works. And it turns out it's, well, long story short, to get builds in CI to use this cache consistently and to use cache to build results from previous builds, it takes a lot of investigation and just fiddling with your ci setup okay to make sure like incremental builds are really fast right because if you're not careful basil will every time you do a ci build it's somewhere else in a different

directory on a different machine right and that causes basil to go look in a different location for your build like cast build results if that makes sense it does i've seen similar issues with c cache on ci systems right just trying to say yes this is in fact the artifact that i want you to use even though the build folder is a different directory or whatever yeah and and then you also have to be careful like the the file system local cache isn't multi-build safe it's meant to be used by one one basal process at a time or one basal server at a time. So you have to be careful to serialize your builds on a given node. Just things like that.

But in the end, it's really paid off. A full build of all our stuff, gRPC, SSL, our code, all this stuff for four Android architectures, four iOS architectures, it's about 20 minutes. And with remote caching, that gets down to like maybe

13 um and then if with if you can use local caching consistently on like a warm node or a hot node um rebuilds are like maybe a minute or two okay so really yeah really really really great handy yeah well dave it's been great having you on the show today um is there anything else you want to let our listeners know about before we let you go? No, I'm good. Just thanks for having me on. I really appreciate it. It was a lot of fun.

Do you have a Twitter handle or anything like that if people want to follow you? I don't. I don't do the Twitter. Okay. You know, I've got my email, right? So, dave.hegedorn at textnow.com if anyone wants to get a hold of me. Alright, awesome. Very cool. Thanks, Dave. Thanks a lot. Yeah, thank you.

Have a good day. You too. 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.