The POCO C++ Libraries Blog

Archive: Development

POCO C++ Libraries in biicode

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

biicode-logo.29235e86

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.

Benefits

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"
#include 
 
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("dict.org");
      const unsigned short PORT = 2628;
 
      if (argc != 2)
      {
            Path p(argv[0]);
            std::cout << "usage: " << p.getBaseName() << " " << std::endl;
            std::cout << "       looks up  in dict.org and prints the results" << std::endl;
            return 1;
      }
      std::string term(argv[1]);
 
      try
      {
            SocketAddress sa(HOST, PORT);
            StreamSocket sock(sa);
            SocketStream str(sock);
 
            str << "DEFINE ! " << term << "\r\n" << std::flush;
            str << "QUIT\r\n" << std::flush;
 
            sock.shutdownSend();
            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:

[requirements]
   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:

[includes]
    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"
 
#include 
#include 
 
/* 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"
 
#include 
#include 
 
/* 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 Team

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.

POCO Team

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
{

SQLiteRegistrator()
{
SQLite::Connector::registerConnector();
}

~SQLiteRegistrator()
{
SQLite::Connector::unregisterConnector();
}

};

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.