Tag Archives: library

SOCI 3.1.0 Released

Posted on by
Reply

It has been a very long journey since version 3.0.0 of SOCI was released. Namely, it’s been nearly three years. The RERO philosophy didn’t quite kick in somehow, but the new SOCI 3.1.0 is finally out.

The latest package can be downloaded from here http://sourceforge.net/projects/soci/ and the complete documentation is part of the package as well as available on-line at http://soci.sourceforge.net/doc/index.html. The project web page reflects the latest changes as well http://soci.sourceforge.net/.

This new release brings all the developments that took place during the last two years and that were up to now somewhat inconveniently available only from our Git repository. At the same time it also defines the snapshot and a basis for subsequent library evolution.

Here extract from the CHANGES file

Version 3.1.0 differs from 3.0.0 in the following ways:

  • Added Ada language binding
  • Migrated build system from GNU Autotools and Visual Studio projects to CMake
  • CMake build tested with Visual Studio, GCC and clang
  • Incorporated a compromise for naming versioned shared libraries
  • Enhanced and improved integration with Boost libraries: Boost.DateTime, Boost.Fusion, Boost.Optional, Boost.Tuple
  • Bug fixes and improvements in core and backends:
    • Added soci::values::get_properties accessor useful for composing soci::type_conversion
    • Export advanced API of backend loader from DLL
    • Added static factory registration functions for backends
    • Added get_affected_rows operation
    • Fixed thread-safety of connection pool under Windows
    • Fixed bug with dropping const qualifiers when binding to std::vector<soci::indicator>
    • Fixed bug in default initialization of an object of const backend_factory which requires user-provided default constructor (see C++03/C++0x)
    • Fixes for 64-bit builds
    • Removed redundant exchange_traits breaking ODR on LP64
    • Better ODBC support
    • Type conversion support for unsigned integer types
    • Bug ID:1971436 – incorrect rowset copy operations
    • Bug ID:2010367 – memory leak (ODBC)
    • Bug ID:2010409 – invalid memory allocation in define by position (ODBC)
    • Bug ID:2021243 – long long type support in Visual C++
    • Patch ID:2483066 – 64bit Linux and 64bit integer submitted
    • Patch ID:2809809 – Fix build with GCC 4.4
    • Patch ID:2809810 – Fix SQLite3 build with GCC 4.3
    • Patch ID:2581206 – Windows Unicode application
    • Patch ID:3058275 – install target for CMake build submitted
    • Patch ID:3069375 – use $(prefix)/lib64 on AMD64 platforms
    • Improved performance while accessing query results (MySQL)
    • Bug fixes for PROCEDURE support (MySQL)
    • Removed throw statements from mysql_rowid_backend and mysql_blob_backend destructors (MySQL)
    • Verify that prepared statements survive session::reconnect() operation (MySQL)
    • Improved support for time and date (MySQL, PostgreSQL)
    • Fixed bug with strings of length exceeding 255 characters (ODBC)
    • Improved interpretation of the connect string (Oracle)
    • Added handling of unsigned long long (Oracle, SQLite3, PostgreSQL)
    • Fixes in integral types support (PostgreSQL)
    • Support for colon-casts (PostgreSQL)
    • Added possibility for use BLOB (PostgreSQL)
    • Added support for connection property “synchronous=on|off” (SQLite3)
    • Improved BLOB data handling (SQLite3)
    • Improved boolean type support (SQLite3)
    • Session timeout support (SQLite3)
    • Improved tests clean-up (SQLite3)
    • Added missing typedef of sqlite3_destructor_type which has been defined in sqlite3.h but since 3.3.10 (see comment for reference to SQLite ticket)
  • Updated tests for various backends and SQL data types
  • Changed naming conventions and style across all the source code
  • Firebird backend removed from official release as not actively maintained. Available in the Git repository
  • Migrated from CVS to Git repository

On behalf of SOCI Team, I’d like to thank all users and contributors who actively helped us to bring the new release to the public. I have tried hard to list everyone in the AUTHORS file. If anyone has been omitted, it happened by mistake and please don’t hesitate to tell me.

Unfortunately, due to lack of active maintenance the Firebird backend has been removed. Also, the ODBC backend needs more love, especially testing. However, we welcome anyone who is interested in taking over the maintenance of the Firebird backend as well as helping us to test and improve the ODBC backend.

As the author of the CMake configuration, I’m strongly interested in any feedback and constructive critique. Please, feel free to post your comments to soci-users. Do you have any ideas for SOCI backends to other databases? Share it!

We are very excited about this release. It allows us to define the directions for future work. There is plenty of ideas to pursue.

Introduction to Boost Geometry slides

Posted on by
Reply

Boost Geometry (aka Generic Geometry Library, GGL)Slides of my very gentle introduction to Boost Geometry library are now available to download from the FOSS4G 2010 website.

The presentation gives a basic overview of the library and tries to explain how it is different to existing solutions but in such way so it’s also understandable to non-C++ programmers. Those who are looking forward to digging out very details of Boost Geometry, I recommend to check presentation which Barend Gehrels gave at BoostCon 2010.

Preparing Quickbook for Boost.Geometry

Posted on by
Reply

Generic Geometry Library (GGL)I’ve just started writing Boost.Geometry (aka GGL) documentation in Quickbook. It is a lightweight format and parser being developed by Boost used to prepare technical documentation for software, mainly for for Boost C++ Libraries. Quickbook files (.qbk) are used as input for BoostDoc which in turn is an extension of DocBook.

Quickbook is a textual format, it feels quite similar to AsciiDoc or some sort of Wiki dialect but dedicated for documenting C++ programming. It is extremely easy to grasp while drinking a single short coffee.

Anyway, it seems it is going to be a quite a book after all elements of Boost.Geometry are documented. One of the challenge I’ve found is to collect all bits necessary to document C++ concepts defined by Boost.Geometry. Unfortunately, Doxygen is not an ideal tool for this purpose, so current version of the documentation lacks of some sections of concepts description. So, I have to dig the source code to find out formal definitions and details of valid expressions and semantics.

Another challenge related to concepts is to find best way to structure their documentation. I started to browse documentation of existing Boost libraries looking for examples and what I found is that there is no best example. Various libraries document concepts in very different way.

A concept is a set of requirements consisting of valid expressions, associated types, invariants, and complexity guarantees

– David Abrahams, Generic Programming Techniques

For example, neatly Boost.Fusion documents concepts with Quickbook, though some elements seem to be omitted. Boost.Graph doesn’t document with Quickbook, looks good, but some details are missing to me, for instance, titles in headers of tables saying what is what is return type and pre-/post-condition for valid expressions, etc. Documentation of Boost.IOStreams concepts sound well. On the other hand, Boost.GIL is an example of why Doxygen should not be used to document concepts of a C++ library.

It looks to me the old good Standard Template Library Programmer’s Guide at SGI is still a best and most complete example of how C++ concepts should be documented.

Given these experiences, I started to think of a way to improve the way concepts are documented within Boost. I believe it would be a good idea to have predefined block for concept in Quickbook. Something along these lines:

[concepttype [Point Concept]
  [this is a concept for 0-dimensional geometry]
  [notation
    [term 1] [description 1]
  ]
  [refinement [concept 1] [concept 2]]
  [associated
    [type 1] [description 1]
  ]
  [expressions
    [name 1 [expr 1]
      [type requirement 1] [return type 1]
  ]
  [semantics
    [name 1 [expr 1]
      [precondition 1] [semantic 1] [postcondition 1]
  ]
  [complexity [...]]
  [invariants
    [invariant 1] [description 1]
  ]
  [models [model 1] [model 2]]
  [notes
    [ note 1] [ note 1]
  ]
  [seealso ...]
]

I posted my proposal to boost-docs list explaining the motivation in details. It’s an interesting experience of a C++ documentation craftsman, anyway. (BTW, Daniel James just announced Quickbook port to Spirit 2.)

When Boost.Geometry release?

Posted on by
1

Generic Geometry Library (GGL)The Boost 1.42 was released a week ago, however this release does not include Boost.Geometry (aka GGL) which was accepted 2 months ago. It is nothing uncommon, though many people have been asking obvious question, why Boost.Geometry is not there and when it will be there.

Boost.Geometry is accepted but with a sticky note attached with a list of issues that need to be solved before the library can be included in official Boost release. It means there is still plenty of work necessary to be done and as soon as they are done and confirmed, we’re in.

Hartmut Kaiser, the review manager, included compete and detailed list of all the issues that need to be addressed in the GGL review results report. Shortly, the contingencies are:

  • Robustness: complete review of all elements of the library to assure it allows to instantiate all algorithms with arbitrary number types. By design, it is possible to specialise types and algorithms of Boost.Geometry with GMP or CLN, so it computes with arbitrary-precision arithmetic. This feature is possible thanks to numeric_adaptor developed by Bruno and Barend. Also, details of computational complexity per algorithms shall be updated.
  • Concepts: during the review, a few problems have been revealed with adapting custom geometries for Boost.Geometry. The concepts are a moral backbone of the library, so they need to be sound making the adaptation process simpler as that’s what the whole idea of concepts in C++ is for.
  • Boolean operations: robustness and coping with different coordinate orders of polygons should be improved.
  • Documentation: currently only Doxygen-based documentation is available. This system does not work well for Boost, so migration to Quickbook system is to be done.
  • Testing: simply, a collection of basic unit tests is not enough and verification of the correctness of the algorithms in a wide range of use cases is necessary along with high volume and random tests.

There are also a few minor issues specified as non-contingencies, however.

It is quite a list and plenty of work that needs to be done and Barend replied on the list:

We’re working on the library, I don’t hope it will take us that long, but 1.42 was not feasable at all. I hope 1.43 but even that is already coming soon.

Tasks dispatched. Fingers crossed.

illegal token on right side of ‘::’

Posted on by
3

libLAS - ASPRS LiDAR data translation toolsetOne of libLAS users reported that when use of #include <liblas/lasreader.hpp> in his application compiled with Visual C++ 10.0 from Visual Studio 2010 cause this error:

utility.hpp(253): error C2589: '(' : illegal token on right side of '::'

The error is an incarnation of a very well-known problem in Visual C++ when using the C++ Standard Library elements, especially the Standard Template Library, in Windows API-based programs. As libLAS library does use the C++ library, so does a user’s application if includes libLAS headers.

The problem is caused by conflicting definitions of min() and max() macros defined in windef.h header. Macros in C++ are scope-less evil, especially if defined in public headers using such extremely unique names as min or max. The fact that Microsoft defined it way before C++ was born absolves them at large, but for the Spirit sake, they should learn the lesson and disable it for good in C++ mode (but not yet another MS-specific way!). No one who’s sane need or want to use them!

Pie in the sky. In the meantime, C++ programmers as the libLAS user who reported this problem have to deal with it on their own. The easiest way is to check CodeProject or Q143208 or search (not google) for solution like #define NOMINMAX for Visual C++ compiler.

However, is another option is to apply a simple trick to call of *::min() or *::max() functions (i.e. std::min() or std::max() which effectively prevents macro substitution, so the Visual C++ compiler (or any other compiler with similar problem) does not complain about illegal token. The trick is to wrap function name, fully qualified name, with parentheses:

(std::min)(x, y);

In most cases of use of C++ Standard Library as described above, it is required for the following functions:

(std::min)(x, y);
(std::max)(x, y);
(std::numeric_limits<T>::min)();
(std::numeric_limits<T>::max)();

In case a user-defined type has a member function with exactly the same name as a macro present in global scope (macros always live in global scope!), it may be necessary to apply the very same trick when a member function is called on an object:

template <typename T, int Size>
struct Series
{
  T min() { return *(std::min_element(s, s + Size); }
  T& operator[](int index) { return s[index]; }
private:
  T s[Size];
};

Series<int, 3> s;
s[0] = 2;
s[1] = 3;
s[2] = 1;

int m = (s.min)(); // long way, but here is the trick

There is one side effect which may be an inconvenience. This trick disables argument dependent name lookup (ADL, aka Koenig lookup).

Boost.Polygon library accepted into Boost

Posted on by
Reply

Boost C++ Libraries Continuing today’s topic of computational geometry, I’m happy to forward one more news from the Boost Community. On November 5th, 2009, after conducting the process of formal review, Fernando Cacciola – the review manager – announced that Boost C++ Libraries officially accepted Boost.Polygon library to its collection. The Boost.Polygon is developed by Lucanus Simonson with support by Intel Corporation.

See Fernando’s message Boost.Polygon library accepted into boost.

I suppose it will be released in Boost version following the upcoming 1.41.0.