CppCast - POCO Project

Episode Date: July 2, 2015

Rob and Jason are joined by Aleksandar Fabijanic to discuss the C++ Portable Components project. Alex holds two undergraduate degrees in mechanical engineering from Faculty of Engineering (University of Rijeka, Croatia) and the master's degree in software engineering from Citadel Graduate College in Charleston, South Carolina. Alex is a IEEE Computer Society Certified Software Development Professional. He's been seriously programming computers since 1992 and developing steel manufacturing automation and process control software using C and C++ since 1998. He used to compete in rowing on World Championship/Olympic Games level. Nowadays, he spends his free time reading, exercising and occasionally woodworking. News Format Specifiers Checking CrystaX NDK 10.2.0 w/ Boost 1.58.0 and Obj-C v2 To Make The Most Money As A Programmer, Learn This Language Aleksandar Fabijanic @0x00FA Aleksandar's Github Links POCO Project POCO on Github Macchina.io

This episode of CppCast is sponsored by JetBrains, maker of excellent C++ developer tools including CLion, ReSharper for C++, and AppCode. Start your free evaluation today at jetbrains.com slash cppcast dash cpp. And by CppCon, the annual week-long face-to-face gathering for the entire C++ community. Get your ticket now during early bird registration until July 10th. Episode 18 of CppCast with guest Alexander Fabrzanek recorded June 29th, 2015. In this episode, we'll talk about a new MSVC feature for Printf. Then we'll interview Alexander Fabrzanek about his work with the Poco project. Alex will tell us how the C++ Portable Components Project will help make for C++ developers by C++ developers.

I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing tonight? I'm doing good, Rob. How are you doing? Doing good. I know we both got some notifications today from CppCon. Do you want to share your news? Yeah, I will be presenting on the current state of free static analysis software for C++. It's going to be a half session. And I'm looking forward to it. Yeah. I got

a notification too. My submission on mobile development was accepted. I'm looking forward to that. Now I need to go and prepare the talk. That's the exciting part. How about you, Alex? I know we haven't introduced you yet, but do you go to any conferences? Yeah, I actually got a notification that

my presentation was accepted. Very good. I'll be speaking on C++ Web WebSockets, and JavaScript, something that we've been doing at Pocro. So I guess we'll meet there in September. Awesome. Well, let me go ahead and give you an official introduction. Alex holds two undergraduate degrees in mechanical engineering

from the Faculty of Engineering in Croatia and a master's degree in software engineering from Citadel Graduate College in Charleston, South Carolina. Alex is an IEEE Computer Society certified software development professional. He's been seriously programming computers since 1992 and developed steel manufacturing automation and process control software using CNC++ since 1998. He used to compete in rowing on World Championship Olympic Games level. Wow. Nowadays, he spends his free time reading, exercising, and occasionally woodworking. Alex, welcome to the show. Thank you.

I'm glad to be here. We've got to talk about a couple of those items. First of all, do you prefer to go by Alex or Alexander yes Alex is fine so real quick tell us about the Olympic game level rowing that's really interesting well it was a long time ago

1992 Barcelona I spent 15 years of my life in the rowing sport and I guess my best achievement was fifth place in the world and seventh place in the Olympics. And so Olympics was a nice experience. Very cool. That's awesome. That is definitely much higher than I've ever ranked in an Olympic sport. No question.

It's a lot of work. It's a lot of work. It's a lot of work, I'll tell you. And, you know, with rowing, you don't really make a whole lot of money. But it was pure love. Yeah, there's no tennis shoes sponsors for rowing, I guess, huh? No, no. Nothing like that. Right.

Okay. Well, before we get into the interview, let's go over just a few pieces of news. The first one interesting. Apparently, printf and scanf arguments, if you're using the wrong type of format specifier or maybe using the wrong number of format specifiers compared to your number of arguments that you're passing in, it'll now mark that as an error or a warning, rather. So that should be really nice. And apparently, Clang and GCC have already been doing that

past versions of Visual Studio could do it by passing in a slash analyze argument but now it'll be just a default compiler warning yeah I didn't realize that it was already previously doing it with slash analyze because I know GCC has been doing this for as long as I can remember yeah probably about 10 years or something. Wow, that long?

Yeah. Yeah, I actually read the Connect issue that someone created in order for them to go and resolve this. And someone said how they basically had a build set up running with slash analyze. And this was the most frequent error that slash analyze would catch and then they would have to go fix a small error and then go do a rebuild so now it'll just be a part of your normal build debug process having this flagged as a warning which should be very nice well i'm always a fan of more things that the compiler can catch for sure

yeah yeah the printf you know it's kind of like one of those things that the compiler can catch for sure. Yeah, the printf, you know, it's kind of like one of those things that proverbial, you know, shooting yourself in the foot. It's very easy to do it with that. Quite honestly, I think, you know, when God created the programmer, you know, it was like, you know, like we have a little child. Let me give this child something to play with and be busy you know because i i can i know probably at least like maybe half a dozen printf like you know solutions and none of them is perfect but it's a good step of course and we should we should strive to kind of get away from that but you know if you have a compiler support to shield you from bad things i

think it's a good thing yeah yeah one of the other interesting things here is there was a note at the bottom saying, you know, this is currently working for C runtime functions like printf and scanf, but if you have your own printf-type functions, they might be able to extend support for that. So if that's something you're interested in, reach out to the author of this blog post, and they might be able to work on that for a future version. Yeah.

Okay, so the next article is, well, it's actually just an announcement that the KristaX NDK, which is an Android NDK, has been upgraded to support Boost 158 and Objective-C version 2, which I thought was interesting. Krista X is an alternative to using the default Android NDK, and it looks like they support a lot more C++ features than the native Android NDK does. And now they even let you build using Objective-C,

which I guess would be nice if you're an iPhone developer trying to bring your app to Android. Do you guys have any? I've seen some issues in Poco where people couldn't build because Define wasn't there or something wasn't compiling. I guess what these guys do, they try to bring it closer to the standards so that you don't have to

specially treat the Android platform. From my understanding, that's what they're doing. And I'm by no means an Android expert. We do have an Android maintainer who takes care of all those things for us. Yeah, it looks like it started off as a fairly small project

just to fill in some of the gaps in the Android NDK, and they've just kind of expanded it from there to give C++ Android developers a better experience. So good work from this team. And the next last article is from forbes and uh to make the most money as a programmer it says to learn this language and uh i'll let you guys guess as to what suggestions they have yeah you can you can you can make good money with c++ but i think I think what they're trying to say there is that if you learn C++, you create a much better foundation for anything else.

It will be easier, say, if you're a C++ programmer, it's easier to switch to Java or C Sharp, then it would be the other way around. And that's a known fact. Plus, I think the people who start with c-sharp and java often you find yourself that you won't do something you know it's under the hood and and it can be tough if you're not familiar with what's going on and you know if you're going to c++ or c so i i think that the the article is you know, it's right on. And I think they're mistaken.

The JVM, I think some JVMs are in C, but there are some that are written in C++. I think the hotspot is in C++. And it's kind of like, it seems like the author is not quite clear about the distinction between C and C++. So it's kind of like, you know, going back and forth. As if C++ is just C with objects, which is somewhat of a misconception in my opinion.

Yeah, I'm not sure if this was written by an actual programmer because they definitely do seem to mix C and C++ together, which is not really accurate these days. Jason, do you have any thoughts on this one? No, I don't. Forbes' website is also blocking me because I have an ad blocker turned on. But I saw the article when it was shared on Reddit also.

Okay. Yeah, I mean, I think C++ is a good language to learn. Yeah. It is. I mean, it's an investment, in my opinion. Obviously, you're going to spend more time, and the learning curve is much steeper than with these other languages. But at the end of the day, it's a good investment.

It's kind of like, you know, if you understand how your car works, you know, if you find yourself without money or without any help, you may be able to fix it yourself. Otherwise, you depend on other people to take care of that for you. Yeah.

Yeah, absolutely. So, Alex, let's talk about Poco. Can you give us kind of a brief overview of it for listeners who haven't been familiar with the library?

Mm-hmm. Yes. Well, you know, actually now that we've talked about Java and C Sharp and all those other languages that kind of have a smoother interface, especially for the beginning, people who are beginning to program, that's pretty much the idea behind Poco, that you create this layer on top of the C++ language and the standard library and give people an easier access to the language. So what we do in InPoco is basically we try to provide a practical help for a programmer so that you can find all the things that you will encounter in everyday programming like threading, logging, networking and

all kinds of things like that. It makes it easier for a beginning programmer to get acquainted with C++ and actually create something functional. Now with that being said, we really try hard not to reinvent the wheel. So we don't have our own string. There's a standard string, for better or worse. In many ways, it's not perfect, but it's there, and we use it. Same thing with the standard containers. Now, with the C++ 11 and 14, that may not be true to some extent because something's not threading came in the standard. We have our own threading, the regular expressions and things like that.

So there is some overlap, but over time in the future, we have our own threading, the regular expressions and things like that. So, there is some overlap, but over the time in the future, we will rectify that. And so, I think that we'll probably say phase out the PCRE and adopt the standard regular expressions and things like that. So, what PO is, when you look at the Poco, what you see is something that looks like a Java class library or.NET framework is just C++. So it kind of gives you an easier way to do things. We go very much by what, what Bjarne Strotsen said, and I'm going to read this here.

This is his quote. Without a good library, most interesting tasks are hard to do in C++, but given a good library, almost any task can be made easy. So, you know, you have a task at hand and you go to do it.

You say, I'm going to do it in C++. If you're, all you have is the language and the standard library, it can be tough. Oh, yeah. So that's where we try to help people. And then, of course, we put emphasis on networking and things like that, without which today you can't really have a modern library.

Yeah. One of the first things you see on the website is that it makes C++ Internet ready. So do you want to go into some of the specifics? What sort of capabilities does Poco provide to C++ developers to make it Internet ready? Sure. That statement in particular, it's somewhat misleading. I mean, yes, we do have a strong networking library, but there's a lot of other things that there are in Poco. So Poco is not a networking library, it's a general purpose framework.

Okay. But it is best known for the networking because it's so easy to create certain things like do sockets or create HTTP server or TCP server. We have support from SSL and TLS, so it's basically all behind the same interface. So it's very easy to turn your socket into a secure socket or your HTTP server into an HTTPS server. So that's why we have this reputation that we are a networking library. What we got in there is you can send email, you know, SMTP client. You can, as I said, you have HTTP server and client,

TCP server and client. There's FTP client, a bunch of things that you can find that are ready to use. So if you want to send an email, you just take, you know, SNTP client and you go, you specify your server recipient, you can add attachments and things like that. So how high level is it? Like if I wanted to grab a file off of an HTTP server, what is that kind of like? You can do it with a one-liner. I mean, there's a one-liner, there's a URL opener, and that'll do it in one line. Or if you want to do a little bit more elaborate, maybe get it in multiple.

Actually, we had somebody recently wanted to, apparently, he had to send multiple requests to receive the file. I guess it was coming in multiple chunks. So in that case, you have to go a little more elaborate. You have to create an HTTP client, and then you would send the request. You'll get the one chunk, then you send another request, get another one. And it's fairly simple. If you want to create a server, you would basically, you create your server, you create your own handler factory and the handlers for different requests

and then it's all downhill from there. So what types of applications are using Poco in the real world? Are there any well-known projects using it? There's a number of... We have a list of probably like maybe 70 or 80 open-source projects and commercial products that are using Poco.

We have Poco used in all kinds of different areas such as building automation, manufacturing automation, it's used in genome sequencing, it's used by some big companies like VMware, it's used by Siemens, Schneider Electric and there are many many others that we know are using it because they download it a lot, but we never hear from them. So, yeah, it is used quite a bit in both open source and commercial applications. All right, so you've already mentioned Android as one of the supported platforms. What platforms, what requirements and compilers do you guys work with? To be honest with you, I'm not all that familiar with that part

because we have a maintainer who takes care of that. But from what I know, it's just GCC and it compiles. What does it work with, Visual Studio? No, no, no. We probably have to do it on on linux but i've never done it myself you know there are so many platforms that you just can't keep up with all those things oh no i don't mean specifically android but i mean just in general does poco work with visual studio oh yes yes of course oh okay okay yeah yeah uh poco is supported pretty much on anything that is C++ standard.

Now, on Windows, we pretty much stick with the Visual Studio. We had some requests. People were asking about the Boron C++ builder. Is that still cool then? I'm not sure, but we never really put a whole lot of effort into that because if you need it, well, you're welcome to contribute it. We will accept it. But there's not so much demand that we would, you know,

it's impossible to support every IDE out there. So basically, Popo will build on anything where standard C++ will build. For POSIX platforms, we have basically um gmake based uh build and then there's a on the on windows we have visual studio we have basically our own uh visual studio project generator so we generated um from scratch for we support back to Visual Studio 2003, which we will drop in the next version because it's been a while. It's time to kind of drop that backward compatibility because at some point it becomes an anchor that's kind of holding you back. We also have a CMake support, which came by popular demand. We didn't have it from the start.

And again, I don't really know anything about CMake. I know there are those files there, CMake, LISP, TXT. But we have a maintainer. One of the Siemens guys, I guess they're using it. And he's doing a really good job of keeping that up to date. So whenever there's an issue, we pass it on to

him. We build on anything, pretty much. iPhone. So you just mentioned one of your older compilers was the one in MSVC 2003. Does that mean you're not doing C++ 11 and 14 support? We don't have yet. That's the embarrassing part. We don't have.

There's a little bit of we're using memory, you know, the alignment where it's available. We have a pending pool for 1.7 release for basically move constructions and things like that. But there's no wholesale C++ 11 support yet. It's coming. So that has to be a pretty big decision because once you start supporting C++11 you start leaving a lot of compilers behind unless you have lots of conditionally

compiled code there. What are you guys thinking about that? Yes, that's why we're so late because it's hard to break code and then you get people come back complaining about it. So essentially it will be, I believe we decided Visual Studio 2012

and GCC 4.8, something like that. That's going to be the new bottom line for anything post 1.7. That makes sense. And, you know, if you're using one of those older compilers and want to continue building using Poco, you just would use an older version, right? That's right. That's right.

We will still continue to support, to some extent, older versions. I mean, we still have people coming with questions for 1.3, which is, you know, probably like 8-9 years old. It's kind of a pain to support multiple branches, but I guess it's just part of life of the maintainer. Yeah, you're right. The hard part is to make that decision, because otherwise, if you try to support both, it's going to be a mess of if-de everything definitely be a mess yeah yeah yeah so you just

mentioned that uh you know you have some issues that are eight or nine years old how old is the poco project exactly poco project was started in 2005 uh the first uh basic, appearance of the code was in February, I believe, and it was started by Gunther Abiltschig. He is an Austrian guy. He has his own company, Applied Informatics, and so he is the original author and founder of Poco. And then I joined shortly after, probably like maybe a month later I I was what I was looking for I was looking for Poco before that I used I used Ace and I used Boost

and I kind of evolved into a C++ programmer from C and then I was using Ace and Boost for a while and I was very envious of Java programmers because they had those big libraries and everything was easy and accessible but I just didn't want to go that way. So when Poco came out in 2005 and I found it, okay, well, this is what I'm looking for. And so I've been contributing ever since.

Wow. So what is your role right now in Poco? It looks like you're one of the main committers today. Are you the main head developer? Yeah, well, quantitatively, I am. I have like over 2 million commits but oh wow

you can't really go you can't really go by that I am pretty much for the most part I'm kind of running the show because Gunther gets

pretty busy with his business and you know so I'm kind of keeping an eye on it and answering questions on the forum and

he chimes in there once in a while and then he's the release and then he's the release master so he's the one who releases I basically and you know we we work pretty well together you know we if there's something that we're unsure we'll check with each other you okay with this you know if I'm unsure if some pool should be accepted then I'll you know and say, hey, are you okay with this?

So that's pretty much how it works. It's between the two of us, we are heading the project. My official title is the project lead, I believe, whatever that means. So is this your full-time job? No, no. Okay. No, no.

I do steel manufacturing automation. That's my day job. Okay. I do consulting on Poco. Occasionally, people come from using Poco in commercial applications, and they need some deep insight and expertise. So they will come to us, and we will do some work from there.

As you can hear, I have a dog over there. Hopefully that won't spoil your show. It's a good dog otherwise. You mentioned steel manufacturing. Are you using POCO in your day job? Yes. Okay. We are using we are using Coco for basically it's an industrial

process control and we kind of it's a it's this layer of functionality that's between your basic

plant floor automation and your business systems so you know the automation that's actually moving the

machinery and on the other side you have the business system that has a scheduling and the material tracking and things like that. So we're kind of in between that where we put all these links together and make sure everything flows. And Poco's done pretty well for us. Okay. I want to wrap this discussion for just a minute to bring you a word from our sponsor, JetBrains. C++ is on a comeback lately, isn't it?

This language has been around for so long, yet it's hard to find a good development tool for it. Luckily, our good friends at JetBrains have just released a new IDE for cross-platform development in C++, and we thought you should know about it. This IDE is called CLion, and it's compatible with Linux, OSX, and Windows. It relies on the well-known CMake build system and offers lots of goodies and smartness that can make your life a

lot easier. CLion natively supports C and C++, including the C++11 standard, libc++, and Boost. But that's not all. Editing CMake files gets a lot easier with CLion, thanks to completion for commands and file names and automatic updating of CMake files. With its in-depth understanding of C and C++ code, CLion brings you smart, relevant code completion. It also gives you full coding assistance, like customizable coding styles, key maps, and project views. You can instantly navigate to a simple declaration or usages, too. And whenever you use CLion's code refactorings, you can be sure your changes are applied safely throughout the whole codebase.

When it comes to version control systems, the IDE supports Subversion, Git, GitHub, Mercurial, CVS, Perforce, via a plugin, and TFS, with a unified interface for all of those. It even has a built in terminal where you can run any command without leaving the IDE locally or remotely using the SSH protocol. A powerful language needs powerful developer tools. With CLion, now you've got those. Download the trial version at jetbrains.com slash cppcast dash C-L-I-O-N. And if you are a student or are developing an open source project, use CLion for free, courtesy of JetBrains. So, you know, thinking about other large open source libraries, would you consider Poco to be a Boost, or are they kind of serving different purposes?

No, I don't consider Poco to be a competitor to Boost. There's some overlap, but we have a lot of people that use both. Really, a lot of people come with questions, and you can see that they're using both Boost and Poco, and it seems that they work for many people in synergy. I guess the difference, you know, when I was using Boost, my main problem was that I wanted to do things like XML parsing or database access, and you don't get that in Boost.

And so, you know know from that practical standpoint well you know it was it was lacking so poco had all of that stuff and then i i had added some of it i you know at that time it was the database access so we have functionality that boost doesn't have and then boost has some things that we don't have. And Boost is more sort of a polygon for standardization, like a pre-standardization. Right. We are not exactly that, although there were some initiatives

to get us included in the standardization process. But I think when you look at poker, the thing is too big to try to squeeze into the standard. It would just never pass. I've been participating a little bit, but it would be probably too difficult to

take, say, PolkoNet library and put it into the standard. Probably, knowing how the standardization works, it's really hard to get things to go through unless you're really highly influential. So you mentioned it's

large, but it's alright if you don't know this off the top of your head. Do you have any idea how many lines of code Poco is right now? You know, I should have run that, but I think last time I checked it was something like 250,000 lines of code. So big, not gigantic. It's come up several times on the podcast

about maintaining gigantic code bases, so I just thought I'd ask. Yeah, too bad I didn't run that. I ran it probably maybe like five, six years ago. So it might be half a million by now. Okay. I see this one thing on the website about doing IoT in C++ and JavaScript using Machina.io based on Poco.

Do you mind just telling me a little bit about that project? Sounds interesting. Sure, sure. Yeah, yeah. That's Gunther's basically new product, his company. And actually my speech at the CPP conference will be somewhat about that. Not exactly about Machina.io, but about underlying technologies. So it's essentially what you have is

there's an open service platform which is an OSGI based application server. I don't know if you're familiar with OSGI. I'm not. I'm not either. You've probably heard of Tomcat. I think so.

It's kind of similar like that. It's an application service. So basically what you have, you have these plugins that are basically called bundles. So what you put in the bundle is obviously your binaries, which are really dynamic libraries, DLLs or SOs. And then you put all the other resources in there, config files, and then you zip it all up, and you put in a certain directory, you configure your server to look at that directory for the application, and then at the runtime, it'll go there. There's a web interface. You can basically install, uninstall bundles, you know, as you're running. There's also a, you can, there's a shell. You can shell into it and then do things, interact with it. And then part of it is there's a interface to JavaScript.

So the idea, back to Machina.io, this was kind of like the foundation of it. And then, you know, back to Machina.io, the idea is to be able to quickly prototype something on an embedded device. So you can create a bundle that's just pure JavaScript. You can load that bundle in your application server. And because application server has a V8 engine in it so it will interpret your JavaScript so you can have a little Raspberry Pi or some kind of embedded device and you can

quickly prototype something or if maybe even create something that would run in production just JavaScript, JavaScript is very trendy now everything is on JavaScript but very trendy now. Everything's on JavaScript. But it's basically, yes, it's

somewhat similar to Node.js, but it's not exactly the same thing because Node.js is entirely asynchronous and single-threaded. Machinarium is not like that.

It's basically you create your JavaScript and it can launch multiple threads. So if you're working on an IoT application, are you writing some JavaScript and some C++ or is the C++ machine I.O. kind of given to you? You can write either C++ machine I.O. given to you? You can write either C++ or JavaScript. So the bundle,

if you think of machine I.O. is basically an application server. And then there are bundles that are plugins in applications that that application server loads. And this application can be written in C++ or JavaScript.

Okay. And when the runtime finds a bundle, it will run it, you know, it will unpack it and it will run it. And whatever language you wrote it in, it's going to run. And the C++ and JavaScript can talk to each other? Yes. Okay. That's powerful.

Sorry, I didn't mean to interrupt you. Go ahead. Yeah. And, yeah,'t mean to interrupt you. Go ahead. Yeah. And, yeah, that's pretty much it. And then you can basically generate the – and I really didn't play a whole lot with Marking.io per se. That's been released fairly recently, but I've been using OSP a lot. So I'm not yet 100% expert on that part.

Gunther will be a better resource for that. But basically what you can do is you can generate a... From the annotations in the comments, there's a generator that will generate your essentially proxies to call from one language to another. So there's no really IDL. You have annotations in the comments and then you run that through a generator and it will generate the stubs to call the other language. Interesting.

Yeah, it's all open source pretty much now, so I can take a look at it on machina.io. Yeah, okay. So we noticed that Poconel supports B code. Is that right? Is that right? Or? Yes. These guys from B code, they actually did all the work. We don't take any credit for that.

Oh, okay. And I think it's a good thing. To be honest with you, I didn't really spend a whole lot of time. I looked at it a little bit. I filed one issue with them on GitHub. And I think it's a good effort. It's a worthwhile effort to have something like that for C++, kind of like we have pip for Python.

You just know it's going to be there for you. It's one of the things on my to-do list that I would like to really try and see if, you know, it really flows good. And I realize sometimes those things can be really powerful and you're just procrastinating and using them. Right. And then when you start using it, you say, how could I live without this? And, you know, the best example is, you know, we were on SourceForge until maybe like three years ago or something like that. And everybody was, you know, people would come and say, hey, move to Git. Move to GitHub. Yeah, yeah, yeah.

Well, you know, it's a lot of work. We don't know anything about it. And then finally at some point, you know, we said, said okay we're going to move and now it's like you see how much more power you get with that tool and how much better your workflow is so perhaps B code is one of those things I can't tell you yet because I didn't

make that transition yet but those guys they're very friendly, very responsive so from that standpoint, I'm sure they will give you all the help they can. So we'll see in the future. Yeah, and for any listeners who haven't heard of B code yet,

it's a dependency and package manager for C++. Do you know if you've seen like an uptick in usage of Poco since it got integrated with B code? There was every time, yes, we do see some of it. Every time there's a mention somewhere on Twitter or

something like that with the B-code, we do see new people coming, there's more stars on GitHub and things like that. So probably this podcast will contribute to that too. Yeah. So I'm sorry.

Oh, you have a phone, huh? Um, our last episode discussed automatic, um, maintenance of projects by, you know, running automated tools that could go through your source code and clean up, you know, particular issues that you deal with and formatting and that kind of thing. I was just curious if you guys deal with that, trying to maintain a large code base, if you have any automated tools for maintaining your stuff? Well, you know, I played in the past with the lint and we don't have any kind of...

we only have our coding style in a document. There's no tool that we're using and there were some promises from some users oh yeah i'll i'll create this and then the other thing but i think uh these clan guys created some formatter that is uh interesting and we would like to use that but in particular because it's not a problem for us you know the core developers we we know our style and we will conform to it but when you get a new contributor and people send you large contributions and they're not conforming it can be really painful yeah you know it it's kind of it it's it's a hard spot because you gotta tell hey now go and remove all your spaces you know you know between the braces and things like that. So, I guess the answer to the original question is we are using

some tools. I use quite a bit the memory checker, Valgrind, I don't even know how to pronounce it. Yeah, something like that. And there's also the doctor memory on windows which i found to be quite quite good what was that i'm sorry doctor memory dr memory oh okay i don't know if i've looked at that one yeah it's kind of like valgrind just it runs on windows it runs on linux too i believe but i use it on windows check that one out for sure. I'm always interested in new tools that help me prove my C++ is correct. Yeah. Valgrind has been quite helpful.

I used it before quite a bit, and it will point out where you're doing something bad. Yeah. And Clang's memory checker. I forget what it's called now. They have an address of sanitizer. Oh, I heard of it. I didn't use it yet. That one I have running in my automated builds also.

Interesting. So are you looking for more contributors to Pocooco or are you always working on new features? Yeah, we are. We are looking for more. We're always on the look for contributors. Right now, we have basically, it's Gunter and myself as core developers and then we have maintainers for various things. And where we don't have a maintainer that it kind of falls on us and it can

be it can be hard you know to to be so familiar with all the different libraries so yes we are looking for contributors uh it's basically we're pretty liberal from that standpoint. Somebody has a library, like recently we got MongoDB library contributed by one of our contributors, MongoDB client library. A library like that does not necessarily have to end up in a release, but it will be in the GitHub and it's relatively simple to just take it and compile it. It's done in the same consistent style like all the other libraries. So, yes, we are looking to get more contributors on board. Are there any libraries you won't accept,

or are you willing to accept any useful functionality? Well, I wouldn't say any because there can be some, you know, morally or legally dubious content. If you want to contribute to the virus, we may say, well, no thanks. All joking aside, as I said, we're pretty liberal.

If you have something that you have done that would fit as a library, say a client or a certain database backend or some kind of a net functionality. For example, recently we had a contributor who contributed some networking functionality. So we decided to take all those kind of extra net stuff and put it in a separate library,

and we declared him the maintainer of it. So go with it here. But that's one of the problems, too, that we had people contribute libraries before, and then they disappeared. Now you're left with people using it, and then they come back, and they want support, and you're not familiar with it,

and we have quite a bit of libraries like that. To flip the question around a little bit, is there any particular library or functionality that you are currently looking to add to Poco? Well, you know, there is something that we are really severely, and it's another one of our embarrassing points, that we really don't have a truly asynchronous I.O. in Poco. And we've been

getting ready to do it for a long time, and we're looking at all kinds of different implementations of how people have died. I'm not sure. It's really a hairy kind of topic to do it really consistently across platforms. The only kind of semblance of asynchronous functionality, we have a reactor framework

which will basically go to whatever you have available on the planet. It's like an e-poll on Linux. On Windows, it will be select for better or worse. But there is no truly asynchronous I.O.

And I've been getting ready to do it. Your desires are always beyond your real capabilities. The physical limitations always kind of hit in. So if anybody is interested

out there to do a asynchronous IO library for Foco, we would welcome that. That's good to know. There might be someone listening. It could be. asynchronous IO library for POCO, we would welcome that. That's good to know. There might be someone listening. It could be. With all these different libraries, are they pretty modular? Is it easy to just bring in parts of POCO, or

should you just bring in the whole thing? No, you don't have to bring the whole thing. They're basically... There are dependencies, of course. Every POCO library depends on foundation. So you can't take a NAT library without a foundation.

But we're very careful about those dependencies that we don't introduce some kind of crazy thing there that will lock you in. You could say if you just want to do networking, you can take Foundation and Net and you're good you don't need anything else. If you need

secure networking then it would be Foundation Net and Net SSL which is really just a wrapper for Net. So if you need secure sockets you know that'll just wrap them. If you want to build your whole application from the scratch, so let's say it's a daemon on Linux or service on Windows, you would need a util library, and a util library has dependency, of course, on

foundation. There is also a dependency on XML and JSON in the util, but you can leave that out if you don't want it. Interesting. I've definitely worked on it. It is modular. That's all right. Go ahead.

I said from that standpoint, it's modular in that sense. We've even seen people take portions of the libraries out, just certain parts of, say, net or foundation, not even the whole foundation,

just take the files that they need and put them in their product and just use them like that. But then you're on your own, because now you have to reconcile that with the new releases and bug fixes and all that. Right. There's an interesting example that you picked out, saying a service on Windows or a daemon on Linux,

because I've worked on a few cross-platform applications that needed to do both of those things, and it would be handy to have a library that would abstract that for you. Right, yes, yes. We have that basically in the UTIL library, there's an application and server applications. So if you just want, say, a command line, there will be an application.

If you want a daemon or service, there's a server applications. So if you just want, say, a command line, that will be an application. If you want a daemon or service, that's a server application. And it will do everything in the... You don't have to worry about it. You compile it on Linux and Windows and it will run the service or daemon. And then if you put a configuration file in the same directory where your application is

with the same name as your application is with the same name as your exit so you put an XML or JSON or dot properties file with the same name as your application it will pick it up automatically and get your configs from there oh wow that sounds really powerful it does well Alex is there anything else you wanted to bring up before we let you go? Well, I really appreciate you guys for giving us this opportunity to publicize Poco even more. As I mentioned, over the course of years, we had well over 100 contributors contributing in various capacities from simple feature suggestions to code patches and blocks to the whole libraries. Without any intention to leave anybody out, we're very thankful for all the contributions

and all of our contributors can be found on the Polko project site and on the GitHub. I would like to name the current maintainers of various parts of Polko. Frank Ibrahim from Belgium is maintainer for the MongoDB, which he wrote and contributed, and also for JSON. Our maintainer for the CMake is Pascal Bach from Switzerland. Our maintainer for the SNMP, ASN, NetX, and Android builds is Rangel Reale from Brazil. And our maintainer for the data access libraries and contributor of the Postgres SQL backend library is Jeff Adams. We're very thankful for all of our contributors, and we do invite more people to join and contribute and use POCO. Thanks.

Hopefully this will help in that process, and I look forward to meeting you guys in Seattle in September. Yeah, I do too. Yeah, absolutely. Where can listeners find you online Alex they can find me on email alex at polkoproject.org they can find me on twitter

0x00FA a magic number they can just google me just put my name it's pretty unique you put the whole name it's pretty unique you can't miss me sure ok well thank you so much for your time

thank you very much thank you Alex ok that was a great episode and I realized right after recording it that we forgot to read this piece of feedback I had. I didn't get any emails. We didn't get any emails this week, but we did get some tweets.

Eva Tsai tweeted at us and was sharing a link to episode 16, which is our news episode, which I think actually turned out to be more popular than we were expecting it to be. That's good to hear. Yeah. But anyway, she seemed to be excited that we were talking about WebAssembly in episode 16. And I shared with her that we're

actually going to be talking about WebAssembly again next episode. We're going to have J.F. Bastian on the show from Google. And I believe he is the author of the WebAssembly spec. That should be a very interesting episode. Yeah, it really

should be. I'm looking forward to having him on next week. That's getting into a whole world that I only just vaguely know something about. Yeah, same here. Anyway, I just wanted to share that. So thank you, Eva Tsai, for listening to the show. And we always appreciate hearing what you have to say. So if you have any thoughts on the show, you can email us at feedback at cppcast.com,

tweet to us at twitter.com slash cppcast, or like us on Facebook at facebook.com slash cppcast. Okay. I think that was a good show, Jason. Yes, I think so too. Okay. Have a good one. You too.

Thanks so much for listening as we chat about C++. I'd love to hear what you think of the podcast. Please let me know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic. I'd love to hear that also. You can email all your thoughts to feedback at cppcast.com. I'd also appreciate if you can follow CppCast on Twitter and like CppCast on Facebook. 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.