The POCO C++ Libraries Blog

Archive: Development

POCO Usage Survey – Results

Filed under: Development by guenter at 22:01

After having it open for 20 days, I have closed our POCO Usage survey today. We’ve collected 53 responses in total which is not really that much but at least something to work with. So, without further ado, here are the results:

Question 1: Which POCO libraries are you currently using in your project?

We clearly see Foundation, Net and Util being the most popular libraries.



Question 2: Which POCO version are you using?

Release 1.6.0 dominates with over 50 %, followed by 1.4.7 and 1.6.0.



Question 3: What platforms are you using POCO on?

Linux (79 %) narrowly beats Windows (~70 %), followed by OS X. We also have Android, iOS and Embedded Linux.



Question 4: Which compilers are you using with POCO?

The POCO user community prefers current compiler versions. On Windows, Visual Studio 2013 dominates followed by Visual Studio 2015. Interestingly, Visual Studio 2010 is used by twice as many as Visual Studio 2012. Regarding GCC, 4.9 and 4.8 are top, as well as Clang/LLVM 3.6.



Question 5: How do you like POCO?

We get a good 1.4 average. Most users find POCO great, one finds it sucks…


Question 6: Please tell us in what kind of project you are using POCO

Here we see everything from games, cross-platform desktop software, big data to different kinds of devices.

Question 7: What feature(s) would you like to see in POCO?

Unsurprisingly, top requests are for better C++11/C++14 support and asynchronous programming (go Alex!). Some people also would like to see better documentation.


For me, there weren’t really any surprises in the answers. It shows that we’re on a good path.
With upcoming release 1.7, we’re starting to move towards full C++11 and C++14 support. Given that most POCO users are on recent compiler versions, I also think we can specify minimum supported compiler versions for 1.7 to Visual Studio 2013, GCC 4.8 and Clang/LLVM 3.6, which will make our way towards C++11/14 much easier. Support for asynchronous programming has been on our roadmap for quite some time now, and if time and resources permit, we may have something coming this fall.

POCO Usage Survey – Please Help

Filed under: Development by guenter at 19:52

I’ve created a short survey on SurveyMonkey
to get some insights how POCO is being used. Please take it – should not take more than three minutes. Your input will help us make future POCO releases better. Thank you!

POCO C++ Libraries in biicode

Filed under: Development,News by guenter at 15:58


The POCO C++ Libraries are now available via biicode, in the following versions:

The following post has been contributed by Fran Ramírez from the biicode team. You can also find the original post on the biicode blog.


biicode is a file based dependency manager, which has many advantages:

  • Save time reusing from any POCO library (Foundation, Net, NetSSL_OpenSSL, etc.) such times as you need and avoid to configure and build out the libraries first. biicode’ll only retrieve the necessary files to build your project.
  • POCO depends on external libraries like zlib, PCRE (Perl Compatible Regular Expressions), HPDF, 7-Zip, OpenSSL and SQLite that they’re uploaded on biicode and maintained by our users.
  • It’s been tested on biicode in Windows with Visual Studio 10 and Visual Studio 12, Linux with GCC and Apple with CLang.

I recommend you to use Visual Studio to configure your project because with MinGW you could get some errors.

POCO External Dependencies

These libraries have many external and third party dependencies to build some of them, e.g., Foundation depends on PCRE and ZLib. Without biicode PCRE and ZLib source files must be present in POCO project, but with biicode it’s not needed. The following table shows all the dependencies for every version uploaded which biicode’ll find if you use all the modules in a project:

So, you’ll not have to worry about to install or build them, biicode does all the effort for you 😉 . These are the depending blocks in biicode:

  • PCRE(v8.36): fenix/pcre
  • PCRE(v7.8): fenix/pcre(v7.8)
  • HPDF: fenix/hpdf
  • zlib: zlib/zlib
  • 7-Zip: fenix/7z
  • OpenSSL: lasote/openSSL(v1.0.2)
  • SQLite: fenix/sqlite

Using POCO C++ Libraries In Your Project

1. Create a new project and an empty block:

$ bii init poco_sample
$ cd poco_sample
$ bii new myuser/myblock

2. Add your sample code (orignal code from Net/samples/dict.cpp) into ./blocks/myuser/myblock/sample.cpp:

// dict.cpp
// $Id: //poco/1.4/Net/samples/dict/src/dict.cpp#1 $
// This sample demonstrates the StreamSocket and SocketStream classes.
// Copyright (c) 2005-2006, Applied Informatics Software Engineering GmbH.
// and Contributors.
// SPDX-License-Identifier:	BSL-1.0
#include "fenix/poco/Net/include/Poco/Net/StreamSocket.h"
#include "fenix/poco/Net/include/Poco/Net/SocketStream.h"
#include "fenix/poco/Net/include/Poco/Net/SocketAddress.h"
#include "fenix/poco/Foundation/include/Poco/StreamCopier.h"
#include "fenix/poco/Foundation/include/Poco/Path.h"
#include "fenix/poco/Foundation/include/Poco/Exception.h"
using Poco::Net::StreamSocket;
using Poco::Net::SocketStream;
using Poco::Net::SocketAddress;
using Poco::StreamCopier;
using Poco::Path;
using Poco::Exception;
int main(int argc, char** argv)
      const std::string HOST("");
      const unsigned short PORT = 2628;
      if (argc != 2)
            Path p(argv[0]);
            std::cout << "usage: " << p.getBaseName() << " " << std::endl;
            std::cout << "       looks up  in and prints the results" << std::endl;
            return 1;
      std::string term(argv[1]);
            SocketAddress sa(HOST, PORT);
            StreamSocket sock(sa);
            SocketStream str(sock);
            str << "DEFINE ! " << term << "\r\n" << std::flush;
            str << "QUIT\r\n" << std::flush;
            StreamCopier::copyStream(str, std::cout);
      catch (Exception& exc)
            std::cerr << exc.displayText() << std::endl;
            return 1;
      return 0;

3. Choose which uploaded POCO version you want to depend on, configure it through your ./blocks/myuser/myblock/biicode.conf file. Create it and copy the following:

   fenix/poco(v1.6.0): 0

4. Finally, you’d only have to retrieve your POCO dependencies and build your sample.cpp. For it, use this command:

bii cpp:build

Note: for Windows users, to configure your project with Visual Studio, e.g., 10 version, execute:

$ bii cpp:configure -G "Visual Studio 10"
$ bii cpp:build

So, biicode’ll download all the dependencies from release version 1.6.0 and compile the project. Now, you can run the binary created in your ./bin/ folder.

Use The Original #include's

Change all the includes from the previous sample.cpp code to:

#include "Poco/Net/StreamSocket.h"
#include "Poco/Net/SocketStream.h"
#include "Poco/Net/SocketAddress.h"
#include "Poco/StreamCopier.h"
#include "Poco/Path.h"
#include "Poco/Exception.h"

Now, tell biicode how to find this dependencies, so, modify again the biicode.conf and add the following:

    Poco/Net/*.h: fenix/poco/Net/include
    Poco/*.h: fenix/poco/Foundation/include

Warning: take care with Poco/*.h: fenix/poco/Foundation/include because it should always be at the end of [includes] section for being a really wide search pattern.

Finally, clean the metadata and build again the project:

$ bii clean
$ bii cpp:build

Creating A Project With NetSSL_OpenSSL or NetSSL_Win

Making a project using these libraries is a special use case of original includes. Why? Take a look at the following example:

#include "Poco/URIStreamOpener.h"
#include "Poco/StreamCopier.h"
#include "Poco/Path.h"
#include "Poco/URI.h"
#include "Poco/SharedPtr.h"
#include "Poco/Exception.h"
/* headers in Net library */
#include "Poco/Net/HTTPStreamFactory.h" 
#include "Poco/Net/FTPStreamFactory.h"
/* headers in NetSSL_OpenSSL and NetSSL_Win libraries */
#include "Poco/Net/HTTPSStreamFactory.h" 
#include "Poco/Net/SSLManager.h" 
#include "Poco/Net/KeyConsoleHandler.h" 
#include "Poco/Net/ConsoleCertificateHandler.h"
/* Main code */

Like you see, NetSSL_OpenSSL and NetSSL_Win have the same relative inlcude headers, so, the only way to resolve successfully your dependencies is writing the full path for them.

#include "Poco/URIStreamOpener.h"
#include "Poco/StreamCopier.h"
#include "Poco/Path.h"
#include "Poco/URI.h"
#include "Poco/SharedPtr.h"
#include "Poco/Exception.h"
/* headers in Net library */
#include "Poco/Net/HTTPStreamFactory.h" 
#include "Poco/Net/FTPStreamFactory.h"
/* headers in NetSSL_OpenSSL library */
#include "fenix/poco/NetSSL_OpenSSL/include/Poco/Net/HTTPSStreamFactory.h" 
#include "fenix/poco/NetSSL_OpenSSL/include/Poco/Net/SSLManager.h" 
#include "fenix/poco/NetSSL_OpenSSL/include/Poco/Net/KeyConsoleHandler.h" 
#include "fenix/poco/NetSSL_OpenSSL/include/Poco/Net/ConsoleCertificateHandler.h"
/* Main code */

The biicode.conf would be like the previous one.

Build All POCO Samples

Try to build all the available samples Poco brings us with each release. Create a project, open any examples/poco block and build it, e.g., examples from 1.4.7p1 version:

$ bii init samples_1_4_7p1
$ bii open "examples/poco(v1.4.7p1)"
$ bii cpp:build

So, that’s all! POCO C++ Libraries are amazing and I strongly recommend you to start using them for your network projects.

I hope you enjoy with this post and don’t forget check our complete C++ documentation! If you’ve any doubt, contact us through our forum or ask directly in Stackoverflow.

POCO 1.5.3 Release Candidate 1 Available

Filed under: Development,News by alex at 05:06

Release Candidate 1 of POCO 1.5.3 has been tagged on the GitHub. Release 1.5.3 is scheduled for June 30 2014.

POCO 1.5.2 Release Candidate 2 Available

Filed under: Development,News by alex at 02:02

Due to a significant amount of fixes during the last week, 1.5.2 Release Candidate 2 is now tagged on GitHub.

Please report any problems back to this list or as a GitHub issue.

To allow for more testing, release projection was pushed forward a week, to June 24 2013.


POCO 1.5.2 Release Candidate 1 Available

Filed under: Development,News by alex at 06:26

1.5.2 Release Candidate 1 is now tagged on GitHub:

Please report any problems back to this list or as a GitHub issue.

Release is projected for June 17 2013.


Library AutoiNEATialization

Filed under: Development,Tips & Tricks by alex at 18:00

In some of POCO libraries (Net on Windows, Data back-ends, Crypto, NetSSL …), there is a need for early library initialization. This task has been done so far in a couple of ways (neither elegant) – we either

  • (1) call initialization (repeatedly) from some strategic points in the library (Net, SSL) that we know will get hit early, or
  • (2) mandate early explicit call (un)initialization (Data back-ends) early from user code.

So, the question here is: can we (and, if the answer is yes, how?) improve the current state?

  • Problem: do tasks early at application init or shared library load, ensuring they are executed prior to any other activity depending on them.
  • Examples: Windows network initialization, DB back-end registration with front-end registry …
  • Solution: looks simple at first, then not so simple when the reality of (1) dynamic/static linkage (on Windows in particular), (2) static variable initialization timing/order and (3) dynamic library loading order (e.g. Data and back-end libraries) hits.

At first, one would think this (SQLite back-end with abbreviated names used as an example here) will do the trick:

// Connector.h:
struct SQLite_API SQLiteRegistrator




extern "C" struct SQLite_API SQLiteRegistrator sqliteRegistrator;

// Connector.cpp:
SQLiteRegistrator sqliteRegistrator;

Alas, MSVC will disregard your wishes in both static and dynamic library builds when it sees that the registrator is “not used” anywhere. Luckily, there’s a way to force the linkage:

#pragma(comment (linker, "/include:_sqliteRegistrator")

With some ifdef-ing for 64-bit (no underscore decoration) and dynamic exports, it turns out that the task is achievable:

#pragma(comment (linker, "/export:sqliteRegistrator")

So, now we have a way to force initialization without having to explicitly call registerConnector from user code (or peppering library with initialization code).

Details are in GitHub repo (Net and Data back-ends only at the time of this writing).

This modification was tested on Windows, Mac and Linux, static and shared builds; I’m putting a word out to hear comments and make sure I did not miss something important, so suggestions are more than welcome. I’d like to have this in the upcoming 1.5.2.