[Liblas-devel] Indexing for point clouds

[Mateusz Loskot]

Hamish wrote:
> Also, I've been meaning to send a note about the C/C++ ABI stability
>  issues. There was a thread on the DebianGIS list about GDAL's C/C++
>  ABI and who should link to what. The result was that the C ABI was 
> heavily favoured for external apps to use even though internally GDAL
>  is written in C++. Maybe it is just GDAL specific -- you can read 
> Frank's comments at the following link, possibly it gives you some 
> ideas for how to handle this in libLAS.
> 
> http://thread.gmane.org/gmane.comp.gis.grass.pkg.general/1230/focus=1286
> 
Personally, I really don't like this approach because it causes a lot of
problems on the level of development (not use) of software.
The core (in GDAL, libLAS, others) is written in C++ but higher
priority is given to C API. Whenever you want to update the core
(written in C++), you have to check if it breaks anything in the C API.
Perhaps GDAL C solves problems for users, but it makes more troubles to
developers and maintenance by slowing down improving and
evolving the project, not to mention *confusing* users - the proof is
what we can observe - people use GDAL C or C++ API or even mix them
together!

Shortly, for me this approach is like a cyclic dependency
which is hard to solve.

I understand the ABI problems and that users like to have things written
once and use forever, but at the same time I'm very sure this approach
is no longer valid today.

Instead, it's better to promise compatibility of C++ API within major
milestones but to not to promise it between major versions.
Just like it is done in Boost C++ Libraries - and nobody complains that
1.38 has tons of new API comparing to 1.34.

Or, just like it's done in GNOME, GTK, libxml and others - physically
separate development of core and API wrapper and make the core higher
priority but the wrapper following (slow, fast or very slow) what
happens in the core. See GTK+ (C) and Gtkmm (C++).

Regardless of my personal disappointment about the C++ vs C API in GDAL,
I'm not going to force any other approach in libLAS.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net