Overview
Features
Download
Documentation
Community
Add-Ons & Services
The POCO C++ Libraries Blog

More Data Results

Filed under: News by alex at 16:53

A couple of new features supported by PocoData:

  • multiple resultsets (for batches of statements and stored procedures/functions returning cursors)
  • step – variable number of fetched rows
  • Date and Time binding/extraction (in addition to DateTime)

The step feature only works for connectors that support it (e.g. ODBC), otherwise it is silently ignored (e.g. SQLite).
Date and Time were broken down because they are handled separately in ODBC. DateTime remains valid binding/extraction for timestamp fields.

All is properly documented

7 Comments »
  1. Great, Alex! Special thanks for keeping the documentation in good shape.

    Comment by guenter on November 12, 2007, 17:57

  2. Hi,

    I found POCO a quite interesting and powerful(I mean handy) library. But there’s one thing prevents me from using it – supporting for wide characters. For example, I once wished to use your logging facilities. You’ve been hard-coded std::string into the interfaces whereas std::wstrings and L”"s are used in my application.

    Do you have any plan to template-ise your interface like the C++ Standard Library? That’ll be a killing feature for me since I use UNICODE in every application I write.

    Thanks.

    Comment by tom on November 29, 2007, 05:41

  3. Tom,

    Templatization would not help in Unicode case. wchar_t is two bytes on windows, but the size is not guaranteed across different platforms (it is usually 4 bytes on *NIX). That is why POCO is UTF-8 based (POCO_WIN32_UTF8 macro enables this on Windows). You can convert your strings between UTF-16 and UTF-8 using UnicodeConverter.

    HTH

    Alex

    Comment by alex on November 29, 2007, 12:49

  4. Thanks Alex.

    I must first confess I have very little knowledge about the encodings – I always use wide characters for safe, because my native language is Chinese.

    Will you write a white paper to elaborate your explanation? this is a bit strange(i.e. advanced) to me since almost all other libraries I saw choose the template way. Or if you could provide me some online pages about this , I would be much obliged.

    There’s also two questions about you comments in the “UnicodeConverter.h” You mentioned those helper functions are meant for Windows UNICODE APIs only and probably won’t be useful elsewhere.

    1.
    Since later Windows versions are internally in UNICODE and in VS2005 the “compile as UNICODE” switch defaults to be on, It virtually means there will be too many occurrences of conversions if POCO is used on windows, this is in convenient.

    2.
    Are you suggesting even when using C++ Standard Library, std::string is prefered to std::wstring.

    Thanks,
    Tom

    Comment by tom on November 29, 2007, 14:00

  5. Tom,

    As for the white paper on Unicode, there is definitely a need for one, but when it will be available I do not know at this time. POCO community gladly accepts code and/or documentation contributions.

    The best starting point to learn online is Unicode web site.

    As for the comment “won’t be useful elsewhere”, it should probably be removed since I’m about to use UnicodeConverter for unixODBC Unicode support on non-windows platforms. Never say never ;-)

    Now answers to your questions:

    1. Unfortunately, any portable framework has to deal with this, one way or the other. If you are developing windows-only, then you can rely on wchar_t being 16 bit and encoding being UTF-16. POCO targets wide variety of platforms and the UTF-8 strategy chosen was well though-out, with all the pros and cons taken into account. This, although it may be an inconvenience sometimes, ultimately turns out to be a Good Thing because one always knows what is the encoding of a string being passed around.

    2. It depends what your needs are. We have std::string and UTF-8 because it provides “seamless” Unicode and ASCII integration. For that purpose, std::string is good enough and works well. Your mileage may vary, depending on what you are doing and which platforms you are targeting. The standard does not specify the size of wchar_t, so it’s up to you to worry about encoding, endiannes and size of the character in std::wstring on the target platform. If you are only targeting Windows, then std::wstring happens to work well with the default encoding (UTF-16) and Unicode. That, however, is not universally true and is an exception, rather than a rule.

    Alex

    Comment by alex on November 29, 2007, 15:39

  6. A correction about the statement on UnicodeConverter above – I intended to extend it to deal with generic 16-bit storage (in addition to std::wstring), but the solution turned out to be a bit different. So, UnicodeConverter will remain Windows-only oddball class ;-)

    Alex

    Comment by alex on November 29, 2007, 16:24

  7. Thanks. It’s a good learning.

    Comment by tom on November 30, 2007, 14:11

RSS RSS feed for comments on this post. TrackBack URI

Leave a comment