The POCO C++ Libraries Blog

It Just Works

Filed under: News by alex at 21:24

I love things that “just work”. Ubuntu distro is supposed to be one of those things. Some time ago, I tried to install it on an old laptop and ended up with LCD panel split in three screens (I’m not kidding) and mouse popping up all over the place. Then I tried Mepis and I ended up with a crystal clear 1280×1024 resolution – something I was never able to achieve myself (who the heck has time and patience for xorg.conf), not even with Gentoo.

Ah, yes, Poco::Data:

I had one main thing in mind when I pushed for Poco::Data – I wanted to throw in a SQL and automagically get out whatever the heck I need – a HTML table, an XML document or whatever else an end user may need. After almost a year (bear in mind, this is still a hobby of mine) of development and tweaking, I finally got where I wanted to be, so we can do this now:

std::cout << RecordSet(session, "SELECT * FROM Simpsons", new HTMLTableFormatter);

and get this out:

Name Address Age
Homer Simpson Springfield 42
Marge Simpson Springfield 38
Bart Simpson Springfield 12
Lisa Simpson Springfield 10

Now, ages may be inaccurate since I made them up, but the code works. For details, see RowFormatter sample.

Unicode (shudder) support code is in, for both Windows and *NIX. It has been fully tested on Windows only, since things are quite murky on *NIX with wchar_t being (mostly) 32-bit, unixODBC Unicode being 16-bit by default (with 32-bit option), iODBC being 32-bit (only) and drivers being all over the place. I’m still trying to make sense of that mess and come up with a coherent strategy.

Comments, bug reports, opinions, flames, peanuts, … all welcome.


  1. Wow!

    This will work together great with something I plan to release next week: a C++ Server Page compiler. It will compile C++ contained in HTML pages into a HTTPRequestHandler class. The thing uses basic JSP syntax (< %, %>, etc.) and it has saved me a lot of work in a previous project. I still have to clean up the code a bit and write documentation. More on it next week.

    Comment by guenter on January 6, 2008, 22:43

  2. Ah great. I thought about it long time ago, in my servlet days. So, your page compiler, in turn, will work great with the servlets.

    Paschal, are you tuned in?

    Comment by alex on January 7, 2008, 00:52

  3. Just tuned in!
    This is simply exciting news. HTTPServer, Servlets and now Server Pages … should this be called CSP ?. C++ has finally joined the internet party in a big way.. because of Poco.

    You guys are geniuses.

    Comment by Paschal on January 7, 2008, 02:25

  4. Can’t help thinking that it would be worth talking to these guys if there are any issues relating to creating de-factor standards for this sort of thing.

    Note to self: have a POCO port of libFastCGI: must send it along.

    Comment by James Mansion on January 11, 2008, 13:17

  5. James,

    While talking to other projects and trying to merge may seem like a good idea initially, it is our experience that usually it does not bear much fruit and proves to be a waste of time. We tried it with SOCI and Platinum. The main reason for failure is that ultimately none of the options turns out to be aceptable for both sides. Merging is a tough thing and people (including us) usually stick strongly to their code. While I may be willing to consider molding PocoServlet code to meet Total Knowledge half way, I would not be willing to give up Poco::Net dependency in favor of socket++ and would not be willing to have firm Apache dependency. That being said, we are very interested in your fastCGI code (I had plans myself for it) – it would be a nice addition to the servlet library, so if you are willing to contribute it, by all means do so. Recently, Paschal has ported all the Tomcat samples (I’ll submit them, I hope, this weekend) to SVN.

    Also, this reply is by no means meant to discourage you to talk to CppServ folks. Please do talk to them if you have time and enthusiasm, but be aware what you may be facing.


    Comment by alex on January 11, 2008, 14:08

  6. Few additions to Data SVN trunk:

    • SQL logging channel and archiving strategy
    • row formatting refactored
    • affected row count for insert, delete and update returned from Statement::execute()
    • internal SQL string formatting capability using Poco::format()

    Comment by alex on January 12, 2008, 20:57

  7. This would also be cool in my opinion

    std::cout << RecordSet(session, “SELECT * FROM Simpsons”, new JSONFormatter());


    Comment by paschal on January 15, 2008, 21:00

  8. It absolutely would. Anyone willing to contribute ? 😉 (it’s only two virtual functions, see the sample).

    In the meantime, few data modifications:

    • fix for this SF bug report
    • use() takes reference now (this may break some code that should have been broken in the first place)
    • bind() for constants (this is for const char* and other consts – it’ll make an internal copy of the value)
    • Statement: allow for easier external binding supply (this is for Brad, I hope it makes him happy 😉


    Comment by alex on January 16, 2008, 05:39

  9. Do you plan to support binding by name?

    Something like this:

    string addr = “…”;
    session << “update person ”
    “set main_address = :addr, contact_address = :addr ”
    “where id = 7”,
    use(addr, “addr”), now;

    It is very useful — never make an error in order of parameters.

    If it can be implemented as some extension of existing implementation please let me know.

    Comment by mike on February 6, 2008, 23:53

  10. This is easily doable for POD bindings and some databases (SQLite for sure), but the only truly portable way across all databases that I can think of would be to massage the SQL string and replace the placeholders before execution or turn placeholders into question marks and provide sufficient amount of bindings. Things then get more complicated when bindings are containers or complex types such as tuples or objects. Even more complicated for containers of tuples or objects. And yet more complicated for bulk execution. The solution I’d be willing to add as a feature should work in all of the above cases.


    Comment by alex on February 7, 2008, 02:58

  11. Mike,

    I gave it a bit of thought today and it may actually be easier than I originally thought. Would you be willing to put in some work and turn it into an actual feature?


    Comment by alex on February 8, 2008, 02:29

RSS RSS feed for comments on this post. TrackBack URI

Leave a comment