Slides are available on SlideShare
April 13, 2013
March 6, 2013
Stable release 1.4.6p1 contains various bugfixes and a few minor new features. See the CHANGELOG for the details.
February 10, 2013
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:
struct SQLite_API SQLiteRegistrator
extern "C" struct SQLite_API 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.
February 9, 2013
Over at the Applied Informatics website we have a new blog. The articles posted so far have covered topics like the Internet of Things, using POCO on Windows CE and iOS and Implementing UPnP Control Points on the iPhone.
January 24, 2013
Data from external sources comes in diverse types and brings along the need for datatype conversion. How can a C++ programmer accurately and efficiently transfer data from relational or XML database to JSON or HTML without stumbling over the C++ type checking mechanism? The answer is by using type erasure techniques; session will enumerate, explore and compare the most popular C++ type erasure solutions.
Given the above problem as well as both historical (ANSI C union and void*, MS COM Variant, boost::[variant, any, lexical_cast]) and recent (boost::type_erasure, Facebook folly::dynamic) development trends (including pending boost::any C++ standard proposal), it is obvious that there is a need for a way around the static nature of C++ language. There is also more than one solution to this problem; session will explore the internals of boost::[variant, any, type_erasure], folly::dynamic and Poco::Dynamic. Design, capabilities as well as pros and cons of each solution will be examined. Performance benchmark comparisons will be reviewed as well.
Type safety is an important feature of C++; type erasure is a necessary technique for modern software development. Session examines and compares existing solutions to these important concerns.
Stop by if you happen to be in the area or attending the conference.
January 12, 2013
Stable release 1.4.6 brings some bugfixes and minor enhancements. See the CHANGELOG for the details. This is planned to be the last release in the 1.4 series.
Development release 1.5.1 is a major step towards the next stable 1.6.0 release planned for this spring. See the CHANGELOG for what’s new.
December 24, 2012
Merry Christmas from the POCO C++ Libraries and Applied Informatics teams and all the best wishes for 2013!
December 21, 2012
Current development branch is now frozen and tagged as 1.5.1 pre-release in GitHub.
Until release, the development branch will remain frozen and any changes will be pushed to separate branches.
Please download or check it out, run some tests, report bugs, etc.
git clone https://github.com/pocoproject/poco.git
Download links (LF line ending only!):
1.5.1 Release is scheduled for Monday, December 24 2012.
Update: Release was postponed for at least a week. Pre-release archives can be downloaded from:
Update 2: Release is available now:
December 2, 2012
During the month of December, we will be transitioning to GitHub issue tracker. By the end of 2012, all SF issues will be either (a) resolved, (b) discarded or (c) moved to GitHub. Please enter new issues in GitHub issue tracker. If you have a patch, please submit it as a pull request.
November 26, 2012
For the 1.4.5 release, I’ve for the first time put the downloads on GitHub in addition to SourceForge. Since it took a very long time for the downloads to become available on SourceForge (and my frustration with SourceForge has been growing lately, especially after the upgrade disaster), the download page links to the files on GitHub. This lead to an interesting observation. While SourceForge download statistics show around 5.900 total downloads per month for October (which was a new all-time high), as of today GitHub shows a total of 8757 downloads for 1.4.5 after only a week. So where do these contradicting numbers come from? Ideas anyone?