[gdal-dev] Starting a discussion on style and coding guidelines

[Andrew Bell]

On Thu, May 5, 2016 at 8:26 AM, Even Rouault <even.rouault at spatialys.com>
wrote:

>
> Might be a little trickier with GCC, particularly with the new GCC 5 C++11
> *ABI* and the dual ABI thing
> (https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html),
> but if
> I understand well, if people use the same GCC version and do not play with
> _GLIBCXX_USE_CXX11_ABI, linking code compiled with different -std=C++??
> setting
> should work.
>
> I've confirmed it with the following experiment:
>
> $ cat a.cpp
> #include <string>
>
> std::string foo()
> {
>   return std::string("foo");
> }
>
> With gcc 5.2, both
> g++ -std=c++11 -fPIC -shared a.cpp -o liba.so
> g++ -std=c++03 -fPIC -shared a.cpp -o liba.so
> result in the following symbol to be exported:
> _Z3fooB5cxx11v
>
> whereas if you add -D_GLIBCXX_USE_CXX11_ABI=0, the symbol name is _Z3foov,
> which is the same as if you compile with GCC 4.X
>
> So the potential problems would be when linking a GCC 5 compiled GDAL
> (whether
> it be C++03 or C++11) against a GCC 4.X compiled lib (think of one of the
> SDK), so this might already occur currently. Or reversely, if an
> application/library compiled with GCC 4.X would link against GDAL compiled
> with GCC 5.X
>

ABI compatibility is a mess: https://isocpp.org/files/papers/n4028.pdf

With that in mind, what you do inside your own codebase isn't much of an
issue and I'm guessing that even if GDAL wants to be as accommodating as
possible, maintainers of dependent libraries probably won't take such
care.  In the end, if you're doing development and building things
yourself, you need to make sure you use the same compiler and switches for
everything if you're providing a C++ interface.  Is this a pain?  Yes.  Is
it necessary?  Yes.

As for the notion of replacing some allocations with vectors, well, great.
But the GDAL codebase is creaky in lots of places and to get too particular
about the advantage/disadvantage of vectors seems a little silly.  At some
point it's just reasonable to say that you're only going to support
compilers/systems made after some date/version.  People who don't want to
upgrade a system aren't harmed.  They always have access to an older
version of the library.  There is just so much cruft in GDAL that could
benefit from use of the standard library and C++ 11 that I don't know where
to start.

That said, changing code that works just because you like this or that
language feature always presents an opportunity for bugs to creep in.

-- 
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160505/2f5a3d20/attachment.html>