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

[Even Rouault]

Le jeudi 05 mai 2016 16:49:37, Andrew Bell a écrit :
> 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. 

(Sometimes they want the latest version of the lib for a particular feature on a ancient system.)

> 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 would be interesting if you (or anyone) could list which C++11 features would be killer features
to justify the upgrade to C++11 vs the potential pains that such a move might cause (especially
as I raised in other emails, given the fact that GDAL uses a number of other libs and is used by a number
of other libs)


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

I agree completely with that :-) Especially for parts of the code base that are
not or poorly tested :
http://rawgit.com/rouault/gdalautotest-coverage-results/master/coverage_html/index.html 


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com