Generic Geometry Library accepted to Boost

Generic Geometry Library (GGL) Today, Hartmut Kaiser, manager of the review of the Generic Geometry Library, announced the official results of the review.

Here we go:

Formally this review ended with 12 YES and 2 NO votes. This result reflects the overall discussion and the general consensus of this library being worth to be included into Boost.

It means that formally the Generic Geometry Library has been approved to become a part of Boost C++ Libraries collection. Happy day!

Hartmut also writes:

It is worth highlighting that most of the reviewers emphasized the excellent quality of the library design.

I would like to send out my own kudos to Barend Gehrels and Bruno Lalande, the very core team, who started the project, designed and implemented the high-quality library and eventually released it as Open Source Software.

Formal review of the Generic Geometry Library by Boost Community

Generic Geometry Library (GGL) Nearly a month after sending out request for review of the Generic Geometry Library (GGL), the Boost Community started process of formal review on November 5th, according to the official Boost reviews schedule. The review is being led by Hartmut Kaiser.

Boost Community members interested in computational geometry has posted quite a large number of comments, questions and suggestions. Barend, as the designer and lead developer of the GGL with most comprehensive knowledge about its every particle, has been doing very hard work scrupulously reacting to every feedback.

Today, Hartmut announced we’re halfway through the GGL review and called for sending reviews. Not every feedback from Boost developers and users sent during library review is considered as review response. Some of senders mark their e-mails as not a review. So, now its time to send review votes.

This is first time I’ve been monitoring Boost formal review in details and I have to admit that it was amazing to observe such very particular feedback. Boost Community conducts proper reviews indeed. Even if a library is not to be accepted, it’s extremely useful for developers to give it a go and collect such feedback about their software. Barend Gehrels has been constantly updating the GGL documentation already. I’m going to compile GGL FAQs based the collected feedback.

All (almost) the posted feedback is recorded in the main Boost mailing list archives under thread with subject [boost] [Review] GGL review starts today, November 5th. There are also some forked but related threads like [boost] GGL Extensions and [boost] GGL Review.

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.

Compile-time unit tests

Boost Build V2 includes testing module that provides nice features for running unit tests. A unit test run means a test builds and can be executed performing checks in run-time, however, a unit test can be also based on compilation or even linking result. Yet more surprisingly, sometimes a test is expected to not to compile and such failure is considered as success. It performs compile-time checking in design by contract.

In Generic Geometry Library, some tests use that feature of testing compilation result. For example, this way it’s possible to test the concepts in practice and to ensure that various constructs are not accepted by the library as expected by design.

For example, custom_linestring.cpp source file can be used to perform compile-time and run-time testing. If TEST_FAIL_APPEND is defined, unacceptable constructs are compiled and the compilation is expected to fail. If compiled without TEST_FAIL_APPEND defined, only acceptable code is enabled and regular run-time test performed.

Configuration of such thing is very easy with Boost Build V2. Here is Jamfile.v2 that performs the test for geometries in Generic Geometry Library using compile-fail rule:

test-suite ggl-geometries
    :
    [ compile-fail custom_linestring.cpp
        : # requirements
        <define>TEST_FAIL_APPEND
        : # target name
        custom_linestring_test_fail_append
    ]
    [ run custom_linestring.cpp ]

There are among others also rules like compile, link-fail and link.

The unit tests execution is simple:

mloskot@dog:~/dev/ggl/_svn/trunk/libs/ggl/test/geometries$ bjam | grep passed
**passed** bin/custom_linestring_test_fail_append.test/gcc-4.4.1/debug/custom_linestring_test_fail_append.test
**passed** bin/custom_linestring.test/gcc-4.4.1/debug/custom_linestring.test