illegal token on right side of ‘::’

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).

Testing libLAS with CMake

libLAS - ASPRS LiDAR data translation toolset As a part of CMake configuration for libLAS, I’ve enabled support CTest. It is CMake test driver program that can be used to run automated tests and perform continuous integration. I also registered libLAS at CDash testing server.

CDash aggregates, analyzes and displays the results of software testing processes submitted from clients located around the world

Check libLAS dedicated quality dashboard registration is required it is public project and available for anonymous visitors to browse the dashboard (thanks to Julien from Kitware for quick fix).

Anyone who is would like to build libLAS using CMake and run tests can find details on the CMake article on the Wiki. I would also encourage interested users to issue make Continuous to submit test results to the dashboard.

Feedback kindly wanted!

Co za CUDA!

The singular processing is dead. Long live the multiprocessing.

I can not even imagine effectiveness of exploitation of such a power by issuing little gdalwarp command. GDAL, libLAS, are we ready to squeeze out this CUDA’ny juice?

Co za CUDA! Yes, indeed!

libLAS 1.2.1 Released

libLAS - ASPRS LiDAR data translation toolset Howard just posted announcement about patch of libLAS 1.2.1 release.

Detailed list of fixes includes:

  • #120 – support ‘comma’ as a separator in las2txt
  • #121 – las2txt and txt2las don’t work with the Point Source ID
  • #122 – las2las does not eliminate requested classifications
  • #124 – some files have pad bytes when they shouldn’t
  • #127 – Scan flags is order sensitive
  • #129 – Version.rc doesn’t make the release
  • #132 – Require libgeotiff when GDAL is requested
  • #133 – FreeBSD endian.hpp
  • #134 – GDAL transform translates the points incorrectly when there is a scale or translation on the points
  • #136 – Problem overwritting Reader’s dataoffset due to VLR
  • #139 – txt2las is not setting the point source id correctly for values > 255
  • #140 – liblas 1.2 linking problems due to –with-hide-internals gdal option
  • #141 – lasinfo in not reporting info about point source id
  • #143 – libLAS 1.2 requires GDAL 1.7 (unreleased)
  • #144 – Apps should take in filenames without -i argument
  • #145 – Memory leak from LASWriter / lasspatialreference assignment operator=
  • #148 – No prototype in core.py for LASPoint_Destroy

On behalf of the libLAS team, thanks to all who provided bug reports and patches!

Before delivering next major release of libLAS, there is one big issue that must be fixed. It is problem with large files under Windows 32-bit operating system – ticket #147. Volunteers are welcome to take care of it :-)

I would also like to see completed build configuration based on CMaketicket #52. It is already usable on Unix (GCC) and Windows (Visual C++), so testers are welcome to give it a try and give us feedback.

Building libLAS with CMake

libLAS - ASPRS LiDAR data translation toolset I almost finished crafting CMake configuration for libLAS. It is available from the repository in the main branch. It is possible to build libLAS library and command line utilities configured with most of supported dependencies: GDAL, GeoTIFF and SpatialIndex. Configuration of Oracle and Boost dependencies is not ready yet. It is also possible to install libLAS run-time and compile-time components. Cool!

Detailed story with extensive example of how to use CMake to build libLAS is available here in Trac. I have successfully tested it on Linux (Ubuntu 9.04). I’m going to test & update it on Windows with Visual Studio – generally it (compilation) works but dependencies selection and installation commands haven’t been tested.

I’m very pleased I can officially announce CMake configuration availability. I truly hope to make my life and users life easier – maintenance of Visual Studio projects is just ridiculously tedious and time consuming.

Preparing CMake configuration was a very useful experience and I’m going to use it to improve other projects this way (like SOCI, Generic Geometry Library). I would be happy to see interest in preparing CMake configuration for GDAL/OGR too…any brave hearts out there?

Why CMake? Because CMake is the best build system ever delivered to Open Source community. Full stop.

Projects of all types, ages and sizes evaluated CMake, came to the same conclusion and eventually migrated to use CMake. To give examples of large or established projects, here we go:

By the way, I’ve started collecting custom reusable CMake modules – available from my workshop repository. They can be used to complete, large collection anyway, of standard CMake modules.