The POCO C++ Libraries Blog

Archive: June, 2007

Can Poco::Data Speak C++ as a Native?

Filed under: News by alex at 04:05

Wouldn’t every true C++ programmer talking to a database be happy to be able to do something like this:

RecordSet rset(session, "SELECT * FROM Vectors");
for (RecordSet::Iterator it = rset.begin(); it != rset.end(); ++it)
std::cout << *it;

Or this:

std::copy(rset.begin(), rset.end(), std::ostream_iterator<Row>(std::cout));

No doubt.
Well, if you’re a C++ aficionado and have a need to retrieve some data from a database, your dream has come true – you can do exactly the above with Poco::Data. You can retrieve your data into a STL-compliant row iterator.

I know, I know, OTL, DTL, SOCI, they all have it, in one form or the other. There are gazillions of data access libraries in all the languages. But we are Poco crowd and we love what we do and we like to think that we do it better. In some way, at least.

At this point, I’d like to express gratitude to Peter Schojer, who has put forth the very first effort for Data and SQLite libraries and also to Maciej Sobczak and other authors of SOCI, after which Data was initially modeled.

With this post, I am concluding several weeks of Data development for the upcoming 1.4 release. Unfortunately, I did not make it to the Unicode in this effort. I do plan to address that alongside with bulk operations and multiple recordsets as soon as possible.

But more than anything else at this time, I plan to spend a couple of weeks on the beautiful Croatian coast – America has been very good to me and I love it as my own, but when the rubber meets the road, there’s no place like home 😉

Take care everyone. AppInf folks, see you in St. Jakob in a while.

Update: Ah, I never get it right the first time around. Guenter, I am really thankful to you in the first place for hearing my request for Data library about a year ago.

The latest on Data

Filed under: Uncategorized by alex at 03:54

The latest is null support. Not being able to insert/update and check for nulls was an important shortcoming, so I have pushed it ahead of Unicode.

Now, the following works:

ses << "CREATE TABLE NullTest (i INTEGER)", now;
ses << "INSERT INTO NullTest VALUES(:i)", use(null), now;
RecordSet rs(ses, "SELECT * FROM NullTest");
assert (rs.isNull("i"));
assert (rs["i"] == 0);

Update: the commented portion in italics does not apply anymore (see the reply below)


SQLite is a bit more gracious than ODBC and will accept generic null value. For ODBC, the difference is that when inserting/updating null fileds, data type has to be specified, so the above code looks like this:

ses << "INSERT INTO NullTest VALUES(?)", use(NULL_INT32), now;

The rest is the same. ODBC code will work for SQLite (which will gracefully take any of NullData enum values), while the other way around is not true – ODBC will throw up when fed the generic one.


Code is in SVN, tested on windows with all supported drivers and Linux with PostgreSQL. Comments and bug reports are welcome.

NamedTuple and DynamicAny

Filed under: Uncategorized by alex at 14:40

Since we are doing 1.4 overhaul, I’m not sure what (if anything) to do about following:

DynamicAny NamedTuple::operator[] (const std::string& name)

It would be nice to be able to do this on a NamedTuple:

NamedTuple nt("name", 1);
nt["name"] = 2;

The way it is done right now is deceptive because it does not modify the tuple itself but the copy of DynamicAny returned by NamedTuple::operator [](). The proper way to modify the NamedTuple value is:


In order for the ‘nt["name"] = 2;‘ syntax to work as expected, the return value should be reference. And that’s where the downside comes into play – to return DynamicAny reference instead of copy, one has to have a member container of DynamicAny’s inside NamedTuple, which, in turn, means duplicating all the values, so I’m not sure whether the syntactic sugar is really worth it.

Another option (I did not try this, so there may be some obstacles to it) is to enable DynamicAny to act as a wrapper (hold SharedPtr instead of its own copy of the value). I mean this in addition, not as a replacement, to existing implementation.

Any thoughts on the above dilemma and proposal? I’ll volunteer to implement the changes if any are voted in.

Update: I would rather write programs that help me write programs than write programs, but it was a dumb title for this blog post.

Roadmap Update

Filed under: Uncategorized by guenter at 12:11

I have just updated the Project Roadmap. The major change is that we’ll soon have a 1.4 release containing all the recently developed new stuff that does not quite fit into the 1.3.1 maintainance release (e.g., Event framework improvements, Data improvements, Async I/O). There will be a 1.3.1 bugfix release in the coming days, fixing the known bugs in 1.3.0. After that, we’ll immediately go to the 1.4.0 release, targetting a release timeframe for early July. Any comments on that?

Coming Soon: Async I/O

Filed under: News by guenter at 11:58

During a very relaxing one hour run through the forest yesterday, I suddenly had an idea how to implement asynchronous I/O for streams and sockets in POCO with very little effort. I’m going to try my ideas out today, so you can expect to show up something in the SVN repository tomorrow – it shouldn’t take more than a few hours to implement this, using existing features in POCO.

Update: AsyncIO is in SVN

West Coast to East Coast

Filed under: Uncategorized by guenter at 19:00

Next month I will travel to the USA to give a few POCO trainings. I will be in the San Jose area from July 12 to July 16, and in the Boston area July 17 to July 21. Since I’ve lots of time in between the training sessions, I’d like to meet up with some of you POCO users in that area. So, if anyone is interested of meeting me in person to discuss all things POCO, drop me a line (guenter <at> appinf <dot> com). And, hey Google: Since I’ll be in your neighborhood, I’d be happy to give a tech talk about POCO at the Googleplex. Don’t miss the opportunity 😉

Bug Slashing Day

Filed under: News by guenter at 17:36

Today I fixed most of the currently open bugs reported on Sourceforge. The result is in the Subversion repository and will soon become release 1.3.1.

There are also improvements to the Unix build system. It is now possible to build POCO-based applications and libraries outside of the POCO_BASE directory hierarchy. To do this, you’ll have to define the PROJECT_BASE environment variable to point to the directory where your projects are located. Say you have your project in /home/user/projects/MyApplication, then you’ll have to set PROJECT_BASE to /home/user/projects. POCO_BASE must still be set and point to the POCO directory. It is now also possible to specify a post-build command – a shell command that will be executed when the library or application has been built successfully. You do this by setting a value for the postbuild variable in your Makefile.