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

[Even Rouault]

Le jeudi 05 mai 2016 14:22:03, Jeff McKenna a écrit :
> On 2016-05-05 9:10 AM, Jeff McKenna wrote:
> > On 2016-05-05 5:14 AM, Dmitry Baryshnikov wrote:
> >> Hi,
> >> 
> >> I think it's time to go forward and shift to C++11 in i.e. GDAL 2.2 and
> >> drop old staff as it was with Windows mobile support, VB, etc.
> >> Yes, it may be some regression in ABI, but this is less evil than
> >> support lot of ancient compilers.
> >> 
> >> During our work on cmake build system for GDAL I faced that some
> >> dependency library needs VC2013SP2 on Windows - i.e liblzma, as it needs
> >> C99.
> >> We worked around it by including some logic to cmake, that if VC
> >> compiler is less than specific version the support of dependent features
> >> will be disabled.
> >> 
> >> By the way, the repo with cmake for GDAL is here:
> >> https://github.com/nextgis-extra/lib_gdal
> >> The ubuntu ppa of libgdal2 build using cmake:
> >> https://launchpad.net/~nextgis/+archive/ubuntu/ppa/+packages
> >> Windows builds also using cmake: http://nextgis.ru/en/borsch/
> > 
> > About a month ago I made the hard decision to upgrade my entire MS4W
> > build environment from VC 2008 to 2015.  Driving this is that PHP 7 only
> > supports 2015.
> > 
> > The only GDAL dependent library not supported for VC 2015 is FileGDB
> > (I've seen an Esri developer state that 2015 SDK will be released with
> > their next FileGDB API upgrade).
> > 
> > MrSID 9.5.1 SDK works well with 2015.
> > 
> > I didn't try an ECW 5.x SDK, but the old 3.3 SDK works well with 2015.
> > 
> > Short story is I support future GDAL builds requiring a more recent
> > Visual Studio compiler (2013+), as other projects are already doing so.
> > 
> > For those packagers cringing in the thought of upgrading their whole
> > stack: join the club :)
> 
> I should also note that for compiling Python 3.5.x VC 2015 is the
> supported environment.  Yet another GDAL dependent library that favors
> an upgraded compiler on Windows.

Thanks for your feedback. Although I'd note that upgrading compiler version is 
one thing, and enabling C++11 mode *might* be another, particularly if there's 
a mix of C++ libs linking against each other. But from what I can read, it 
seems that with Visual Studio you don't have the equivalent of -std=c++?? of 
GCC, so if things are compiled with the same VS version, that should be OK.

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

Even

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