[gdal-dev] C++11 timeline

[Andrew C Aitchison]

On Fri, 6 Jan 2017, Kurt Schwehr wrote:

> Andrew,
>
> Have you tried compiling GDAL 1.11 as C++11?

Yes, and even with C++14 (g++ v5.3.1-6), but mixing GCC versions on linux 
is more forgiving than mixing different compilers on most other platforms.

>  I used GDAL 1.11 built as C++11 for quite a while before switching to GDAL 2.x.
>  We aren't talking about changing the internal API for drivers.
>  Or am I missing something?

I was thinking more about A*B*I compatibility when mixing compilers.
I use GDAL 1.11 because the legacy platform I am on (Scientific Linux 6)
only has QGIS 1.8 and the system compiler is C++98 (with C++0x as an 
option - no mention of C++03).

If other people are run-time linking apps not under their control
(either system provided or third party) against GDAL v1.11 libraries
they may not have the luxury of changing compiler, so may have to
build plugins with one compiler for v1.11 and another for v2.x.

Maybe this is the point at which they stop developing
for the older platforms and/or GDAL v1,
but I can see people needing to support GDAL 2.1.current and 2.next
for some time yet.


> On Fri, Jan 6, 2017 at 12:50 AM, Andrew C Aitchison <andrew at aitchison.me.uk>
> wrote:
>
>> On Fri, 23 Dec 2016, Kurt Schwehr wrote:
>>
>> I would like to continue the C++11 discussion over the next couple weeks
>>> while many people are on slower development cycles with a proposal:
>>>
>>> * Starting 2017-Mar-01, we switch GDAL trunk to require C++11 support from
>>> the compiler.
>>> * All prior branches would stick with their existing requirements for
>>> C++03
>>> support
>>>
>>                 ...             ...
>>
>>> This would not be a free-for-all on C++11 features.  I think we would want
>>> to just start with removing some of the macros and workarounds that are
>>> currently in the code base.  Until we decide to go forward with other
>>> features, the main changes that would happen in C++ only code after this
>>> would be:
>>>
>>> - Change NULL to nullptr
>>> - Drop virtual when using the override keyword (this becomes a req with
>>> C++17)
>>> - CPL_OVERRIDE -> override
>>> - Remove HAVE_CXX11 #ifs
>>> - And maybe some other things I missed
>>>
>>
>> Are there many people maintaining/developing *plugin* drivers for gdal
>> - I know of the ECW plugins; are there any others ?
>>
>> I am working on a couple of private drivers for proprietary formats,
>> and find it useful that I can use the same source to build plugins for
>> GDAL 1.11 and 2.1.2.
>>
>> Would the changes to nullptr, CPL_OVERRIDE etc. make it harder to maintain
>> plugin code for old and new versions of GDAL ?