mloskot.devjavu.com moved

Jeff Lindsay announced DevjaVu will be shutting down. This is bad news of the day for me, because I’ve been hosting on DevjaVu my personal workshop repository with miscellaneous prototypes and experiments at http://mloskot.devjavu.com/.

Due to Jeff’s decision, I’ve moved my repo to GitHub where is available as all-in-one workshop repository at http://github.com/mloskot/workshop/:

git clone git://github.com/mloskot/workshop.git

I?d like to send big thanks to Jeff and the DevjaVu team for two years of providing top-notch Subversion and Trac services. Good luck!

Geospatial bits on BoostCon’09

On the 3rd of May 2009, the best event dedicated to C++ programmers starts in Aspen, US. It is BoostCon’09. The conference gathers developers and users of Boost C++ Libraries.

This year the event brings some flavour of geospatial technologies. Barend Gehrels and Bruno Lalande – core developers – are presenting their Generic Geometry Library

    uff. :-)

Be strict or…

…you may have to eat the C++ programming language standard (may be with the C one together, brrr) half-baked or even raw.

GEOS 3.0.0 does not compile using GCC 4.3.3. The compiler complains, surprisingly, about missing functions like std::memcpy (GEOS core is written in C++, not C):

DoubleBits.cpp: In static member function 'static double geos::index::quadtree::DoubleBits::powerOf2(int)':
DoubleBits.cpp:51: error: 'memcpy' was not declared in this scope
DoubleBits.cpp: In constructor 'geos::index::quadtree::DoubleBits::DoubleBits(double)':
DoubleBits.cpp:94: error: 'memcpy' was not declared in this scope

StringTokenizer.cpp: In member function 'int geos::io::StringTokenizer::nextToken()':
StringTokenizer.cpp:75: error: 'strtod' was not declared in this scope
StringTokenizer.cpp: In member function 'int geos::io::StringTokenizer::peekNextToken()':
StringTokenizer.cpp:123: error: 'strtod' was not declared in this scope

These functions come from the C/C++ Standard Library, so how they could be missing? They are because the files reported above do not include standard header <cstring>. GEOS 3.0.0 had used to compiled using GCC without problems, what happened? GCC is just being aligned to the standards closer and closer, so it becomes strict and unforgiving.

There is a lot of C/C++ code of FOSS written in sloppy way being compiled in relaxed mode without use of strict compilation flags. Having in mind number of bugs reported after GCC 4.3 was released, I presume dark clouds are coming again with just released GCC 4.4.0 and upcoming 4.5.0. It’s always a good idea to not to trust chain or implicit inclusion of standard headers – wherever std::malloc is used <cstdlib> must be included, same about std::vector and <vector> and so on.

By the way, this particular bug in GEOS was spotted using GCC 4.3, reported, patched and fix was released as GEOS 3.0.3.