<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, May 5, 2016 at 8:26 AM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"><br></div></div>
Might be a little trickier with GCC, particularly with the new GCC 5 C++11<br>
*ABI* and the dual ABI thing<br>
(<a href="https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html" rel="noreferrer" target="_blank">https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html</a>), but if<br>
I understand well, if people use the same GCC version and do not play with<br>
_GLIBCXX_USE_CXX11_ABI, linking code compiled with different -std=C++?? setting<br>
should work.<br>
<br>
I've confirmed it with the following experiment:<br>
<br>
$ cat a.cpp<br>
#include <string><br>
<br>
std::string foo()<br>
{<br>
  return std::string("foo");<br>
}<br>
<br>
With gcc 5.2, both<br>
g++ -std=c++11 -fPIC -shared a.cpp -o liba.so<br>
g++ -std=c++03 -fPIC -shared a.cpp -o liba.so<br>
result in the following symbol to be exported:<br>
_Z3fooB5cxx11v<br>
<br>
whereas if you add -D_GLIBCXX_USE_CXX11_ABI=0, the symbol name is _Z3foov,<br>
which is the same as if you compile with GCC 4.X<br>
<br>
So the potential problems would be when linking a GCC 5 compiled GDAL (whether<br>
it be C++03 or C++11) against a GCC 4.X compiled lib (think of one of the<br>
SDK), so this might already occur currently. Or reversely, if an<br>
application/library compiled with GCC 4.X would link against GDAL compiled<br>
with GCC 5.X<br></blockquote><div><br></div><div>ABI compatibility is a mess: <a href="https://isocpp.org/files/papers/n4028.pdf">https://isocpp.org/files/papers/n4028.pdf</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>That said, changing code that works just because you like this or that language feature always presents an opportunity for bugs to creep in.</div><div><br></div><div>-- <br></div></div><div class="gmail_signature">Andrew Bell<br><a href="mailto:andrew.bell.ia@gmail.com" target="_blank">andrew.bell.ia@gmail.com</a></div>
</div></div>