• Dynamic C++

This is a “replay” of ACCU Conference 2013 presentation from Bristol, UK.

---

• Look Ma, “update DB to HTML5 using C++”, no hands!

This is an “upgrade” of the Silicon Valley Code Camp 2012 presentation, adding SQLite event callbacks in conjunction with WebSocket, resulting in a seamless ”push” of data from database straight to an HTML5 web page.

Code is in GitHub repository, stay tuned for slides and videos …

Courtesy of Schalk Cronjé tweet – his notes on the ACCU 2013 Dynamic C++ presentation:

Dynamic C++ in a nutshell

Get the source code from the download page or directly from GitHub.

• (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.

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.

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.

Get the source code from the download page or directly from GitHub.

git clone https://github.com/pocoproject/poco.git

Download links (LF line ending only!):
https://github.com/pocoproject/poco/archive/poco-1.5.1-pre-release.zip
https://github.com/pocoproject/poco/archive/poco-1.5.1-pre-release.tar.gz

Latest Commit:
https://github.com/pocoproject/poco/commit/16533ef73b7d4b68c0fac5247769aed800704bc0

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:

https://github.com/pocoproject/downloads/tree/master/poco-pre-1.5.1

Update 2: Release is available now:

http://pocoproject.org/blog/?p=726

—

POCO Team