como adventures with boost/cstdint.hpp

While compiling a program that uses boost/cstdint.hpp from Boost Integer Library:

#include <iostream>
#include <boost/cstdint.hpp>
int main()
{
    boost::int64_t i64 = -2;
    boost::uint64_t ui64 = 2;
    boost::uint64_t d = ui64 - i64;
    std::cout << d << std::endl;
    return 0;
}

front-end of Comeau C/C++ 4.3.10.1 compiler complains:

boost/cstdint.hpp", line 111: error: the
          global scope has no "int64_t"
    using ::int64_t;
            ^

However, if I reorder include directives:

#include <boost/cstdint.hpp>
#include <iostream>

then the program compiles well.

I believe that the order of header files should not be relevant here, but seems it is. I’ve submitted a ticket #3548 to Boost.Integer and I’m curious awaiting the diagnosis.

After this issue is fixed, I’m looking forward building the Generic Geometry Library using Comeau C/C++ compiler. This should help us to maintain high quality of standard and yet more portable C++ code.

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!

Boost will review Generic Geometry Library

Generic Geometry Library (GGL)Today afternoon, Barend Gehrels oficially submitted formal request of the Generic Geometry Library (GGL) to Boost C++ Libraries.

After a long journey through four previews and number of discussions, here and there on Boost mailing list and on GGL mailing list, and through the library presentation at BoostCon’08 and hard work on application of improvements to design and implementation contributed by previews reviewers and also by growing community of users, the Generic Geometry Library project finally has got his D-Day. Today official request has been posted to the Boost Community.

The design of the GGL library is stable. The library provides a variety of coherent functionality. Given that, the library has matured enough for formal review. Fair enough.

The Generic Geometry Library is considered as a general purpose library which is not bound to any specific domain. I believe this goal has been achieved very well. However, every use of a software library is a domain-specific use. Thus, next to built-in features, agnosticism (computing) and extensibility, an idea of GGL extensions has been defined. We* agreed that extensions should be supported in a very similar way to how the Generic Image Library (GIL) does it. So we are going to help to organize development of GGL extensions, where an extension is something more specific to domains, for example domain of GIS applications.

The review is put on the official Boost formal review schedule with Hartmut Kaiser as the review manager. Let’s get this party started:

Formal Review Request: Generic Geometry Library (GGL).

The Boost review itself is quite long, very detailed and fairly exhausting, for a library submitters, process. It feels like a kid standing still in front of a wall and other kids are bombarding him with snow balls. Having in memories process of Boost.Polygon library review I was witnessing a few weeks ago, GGL is going to take zillions of “snow balls” on the chin :-) Fingers crossed!

* I’ve joined the Generic Geometry Library project in April 2008 2009 and since then has tried contribute by evaluating, testing, fixing, porting, improving and extending to some small, hopefully useful, extent.

Talk on Geometry Template Library

Another video from BoostCon’09 conference. This time it is about the Geometry Template Library (GTL) for STL-like 2D operations by Lucanus Simonson and Gyuszi Suto:

Here is PDF document with slides from the conference talk. The GTL library was submitted to Boost C++ Libraries for formal review as Boost Polygon library. Performance was at large a significant subject of posted reviews and discussions. Barend and Bruno from Generic Geometry Library (GGL) have been working hard to build a comprehensive performance study of Open Source geometry libraries available on the market. Results and source code are available.

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.

libjpeg and libpng go C++

I’ve just come across an interesting project(s). It is jpegxx and pngxx: two (or three if imagexx adaptors counted) thin libraries wrapping libjpeg and libpng with interface of C++ streams, iterators and ranges.

It slowly is getting crowded around raster libraries in C++. Another alternative is GIL developed by Adobe and included in Boost C++ Libraries with collection of IO and more extensions.

Just what tigers like best. Isn’t it?