Quantcast

[gdal-dev] C++11 timeline

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[gdal-dev] C++11 timeline

Kurt Schwehr-2
Hi all,

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

I had come up with a bunch of other things for a timeline, but they all see like noise after Even pointed out a whole ton of issues my thoughts.  This isn't as aggressive as I would like, but it would definitely help reduce the maintenance burden on humans and reduce the test load for continuous integration.  I removed explicit mention of OS or compiler versions which I had in my initial thoughts.

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

Once those are all done, we can then discuss when to allow things like unique_ptr internally (which will allow some serious simplification of some code).

Then at some later time, we can discuss what API changes to allow, when to require C++14, C++17, C11, etc.

Thoughts?

-kurt

e.g.

find . -name \*.cpp -o -name \*.h | xargs grep -i override | grep virtual | wc -l
    3998

find . -name \*.cpp -o -name \*.h | xargs grep CPL_OVERRIDE | wc -l
     712

find . -name \*.cpp -o -name \*.h | xargs grep HAVE_CXX11 | wc -l
      36


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

Kurt Schwehr-2
A ping to bring the topic of C++11 back to the front post holidays.

Thoughts?

On Fri, Dec 23, 2016 at 10:05 AM, Kurt Schwehr <[hidden email]> wrote:
Hi all,

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

I had come up with a bunch of other things for a timeline, but they all see like noise after Even pointed out a whole ton of issues my thoughts.  This isn't as aggressive as I would like, but it would definitely help reduce the maintenance burden on humans and reduce the test load for continuous integration.  I removed explicit mention of OS or compiler versions which I had in my initial thoughts.

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

Once those are all done, we can then discuss when to allow things like unique_ptr internally (which will allow some serious simplification of some code).

Then at some later time, we can discuss what API changes to allow, when to require C++14, C++17, C11, etc.

Thoughts?

-kurt

e.g.

find . -name \*.cpp -o -name \*.h | xargs grep -i override | grep virtual | wc -l
    3998

find . -name \*.cpp -o -name \*.h | xargs grep CPL_OVERRIDE | wc -l
     712

find . -name \*.cpp -o -name \*.h | xargs grep HAVE_CXX11 | wc -l
      36




--

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

Howard Butler-3

> On Jan 5, 2017, at 9:08 AM, Kurt Schwehr <[hidden email]> wrote:
>
> A ping to bring the topic of C++11 back to the front post holidays.
>
> Thoughts?
>
> On Fri, Dec 23, 2016 at 10:05 AM, Kurt Schwehr <[hidden email]> wrote:
> Hi all,
>
> 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
>
> I had come up with a bunch of other things for a timeline, but they all see like noise after Even pointed out a whole ton of issues my thoughts.  This isn't as aggressive as I would like, but it would definitely help reduce the maintenance burden on humans and reduce the test load for continuous integration.  I removed explicit mention of OS or compiler versions which I had in my initial thoughts.
>
> 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
>
> Once those are all done, we can then discuss when to allow things like unique_ptr internally (which will allow some serious simplification of some code).
>
> Then at some later time, we can discuss what API changes to allow, when to require C++14, C++17, C11, etc.
>
> Thoughts?

Kurt,

I meant to chime in on this. Thanks for the reminder. I wanted to put forward some of the experience we've had with PDAL on moving to C++11. I think the first question to ask is which compilers does GDAL expect to support, and then compute back from there as to whether or not enough C++11 support is covered by that set. PDAL's situation has been different than GDAL because we're a much younger project, we have a smaller set of compilers we have historically supported, and we have been a bit aggressive about moving forward. Even so, there are a few C++11'isms we don't use because we allow MSVC2013, for example.

I agree that object lifetime management with unique_ptr and some systematic RAII would significantly improve GDAL's internals in terms of complexity and opportunity for bugs., but the refactoring itself is also likely to introduce a few bugs too. The benefits of following a few (not all) established modern C++ patterns would also help bootstrap developers into the GDAL codebase a bit faster as well. PDAL was happy to quit using Boost for its modern C++ library support, and our codebase has been better for it IMO.

I'm not sure that GDAL has this luxury, however. The project would need to migrate with clear acknowledgement of the consequences -- the dropping of support for a number of now-working-but-quite-esoteric compilers. We wouldn't want to #ifdef hell the support of both. Maybe the size of the set that would be dropped is small. We need some feedback from people on the topic to gauge the temperature on it.

To migrate everything to C++11 just for the sake of it doesn't seem prudent, but I agree the long term benefits to the project could be significant. GDAL already has a number of CPL classes that are C++11 -like in terms of functionality they provide. There's been some benefit to doing our own thing and having control over it that might be given up with a move to C++11.

What is the list of compilers that GDAL actively and accidentally supports? How will that be impacted by a C++11 requirement?

Howard

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

Even Rouault-2

>

> What is the list of compilers that GDAL actively and accidentally supports?

 

Currently, at least:

GCC >= 4.4 (actually must be 4.1 since this is what ancient mingw uses)

clang >= 3.something (3.0 probably)

VS >= 2008

ICC 15 probably

 

One aspect is to also consider the various analyzers used. I think cppcheck has only partial C++11 support. I'd guess Coverity Scan should have decent C++11 support but this is just a guess. CLang Static Analyzer should likely work just fine with the C++11 supported by the underlying clang compiler

 

> How will that be impacted by a C++11 requirement?

 

GCC 4.8 is needed for C++11 I think. There are folks using recent GDAL on older distros like Ubuntu 12.04 (which ships with gcc 4.6). I guess they could switch to adding a PPA with a more recent toolchain.

For Visual Studio depends on the features we use. Would be good to have VS2013 or even 2012. I'm CC'ing Jürgen Fischer to know if he has plans regarding of the compiler version that will be used for OSGeo4W / QGIS 3.0

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

Kurt Schwehr-2
Even responded while I was trying to write up something, so I'm going to stop writing and send :)

Howard,

Thanks for the thoughts.  I believe we are thinking along the same lines.

All,

After time for comments, I plan to write up an RFC for the initial strategy that is explicit about assumptions.

Please correct me if you think I'm wrong/missing anything.  Especially when it comes to non-linux / mac builds.

Useful references:


Current explicit supported compilers:

- MS VC9
- MS VC12
- MS VC13
- MinGW 32 (this is old)
- MinGW 64 (newer)
- clang >= 3.0?
- gcc >= 4.6.3.  Even said 4.4

Best effort supported compilers:

- SunPro/Oracle C++ >= ?
- Intel >= ?

My guess at our new situaltion

- MS >= VC13 (I am confused by their version numbers)
- MinGW 32 (newer)
- MinGW 64 (newer)
- clang >= 3.3
- gcc >= 4.8

Best effort supported compilers:

- SunPro >= ?
- Intel >= ?

On Thu, Jan 5, 2017 at 9:26 AM, Even Rouault <[hidden email]> wrote:

>

> What is the list of compilers that GDAL actively and accidentally supports?

 

Currently, at least:

GCC >= 4.4 (actually must be 4.1 since this is what ancient mingw uses)

clang >= 3.something (3.0 probably)

VS >= 2008

ICC 15 probably

 

One aspect is to also consider the various analyzers used. I think cppcheck has only partial C++11 support. I'd guess Coverity Scan should have decent C++11 support but this is just a guess. CLang Static Analyzer should likely work just fine with the C++11 supported by the underlying clang compiler

 

> How will that be impacted by a C++11 requirement?

 

GCC 4.8 is needed for C++11 I think. There are folks using recent GDAL on older distros like Ubuntu 12.04 (which ships with gcc 4.6). I guess they could switch to adding a PPA with a more recent toolchain.

For Visual Studio depends on the features we use. Would be good to have VS2013 or even 2012. I'm CC'ing Jürgen Fischer to know if he has plans regarding of the compiler version that will be used for OSGeo4W / QGIS 3.0

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com




--

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

Andrew Bell
Why is there a desire to support old compilers for new code?  Those that don't want to upgrade compilers can always use existing distributions.

On Thu, Jan 5, 2017 at 11:32 AM, Kurt Schwehr <[hidden email]> wrote:
Even responded while I was trying to write up something, so I'm going to stop writing and send :)

Howard,

Thanks for the thoughts.  I believe we are thinking along the same lines.

All,

After time for comments, I plan to write up an RFC for the initial strategy that is explicit about assumptions.

Please correct me if you think I'm wrong/missing anything.  Especially when it comes to non-linux / mac builds.

Useful references:


Current explicit supported compilers:

- MS VC9
- MS VC12
- MS VC13
- MinGW 32 (this is old)
- MinGW 64 (newer)
- clang >= 3.0?
- gcc >= 4.6.3.  Even said 4.4

Best effort supported compilers:

- SunPro/Oracle C++ >= ?
- Intel >= ?

My guess at our new situaltion

- MS >= VC13 (I am confused by their version numbers)
- MinGW 32 (newer)
- MinGW 64 (newer)
- clang >= 3.3
- gcc >= 4.8

Best effort supported compilers:

- SunPro >= ?
- Intel >= ?

On Thu, Jan 5, 2017 at 9:26 AM, Even Rouault <[hidden email]> wrote:

>

> What is the list of compilers that GDAL actively and accidentally supports?

 

Currently, at least:

GCC >= 4.4 (actually must be 4.1 since this is what ancient mingw uses)

clang >= 3.something (3.0 probably)

VS >= 2008

ICC 15 probably

 

One aspect is to also consider the various analyzers used. I think cppcheck has only partial C++11 support. I'd guess Coverity Scan should have decent C++11 support but this is just a guess. CLang Static Analyzer should likely work just fine with the C++11 supported by the underlying clang compiler

 

> How will that be impacted by a C++11 requirement?

 

GCC 4.8 is needed for C++11 I think. There are folks using recent GDAL on older distros like Ubuntu 12.04 (which ships with gcc 4.6). I guess they could switch to adding a PPA with a more recent toolchain.

For Visual Studio depends on the features we use. Would be good to have VS2013 or even 2012. I'm CC'ing Jürgen Fischer to know if he has plans regarding of the compiler version that will be used for OSGeo4W / QGIS 3.0

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com




--

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev



--
Andrew Bell
[hidden email]

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

jmckenna
Administrator
In reply to this post by Even Rouault-2
MS4W builds are moving to VS2015, because PHP 7's requirement for that
compiler, but stable releases are done now with VS2012.  (I've
officially moved away from the old VS2008)

-jeff

--
Jeff McKenna
President Emeritus, OSGeo Foundation
http://wiki.osgeo.org/wiki/Jeff_McKenna



On 2017-01-05 1:26 PM, Even Rouault wrote:

>>
>
>> What is the list of compilers that GDAL actively and accidentally
> supports?
>
>
>
> Currently, at least:
>
> GCC >= 4.4 (actually must be 4.1 since this is what ancient mingw uses)
>
> clang >= 3.something (3.0 probably)
>
> VS >= 2008
>
> ICC 15 probably
>
>
>
> One aspect is to also consider the various analyzers used. I think
> cppcheck has only partial C++11 support. I'd guess Coverity Scan should
> have decent C++11 support but this is just a guess. CLang Static
> Analyzer should likely work just fine with the C++11 supported by the
> underlying clang compiler
>
>
>
>> How will that be impacted by a C++11 requirement?
>
>
>
> GCC 4.8 is needed for C++11 I think. There are folks using recent GDAL
> on older distros like Ubuntu 12.04 (which ships with gcc 4.6). I guess
> they could switch to adding a PPA with a more recent toolchain.
>
> For Visual Studio depends on the features we use. Would be good to have
> VS2013 or even 2012. I'm CC'ing Jürgen Fischer to know if he has plans
> regarding of the compiler version that will be used for OSGeo4W / QGIS 3.0
>
>
>
> Even
>
>
>
> -



_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

Greg Troxel-2
In reply to this post by Even Rouault-2

Even Rouault <[hidden email]> writes:

>> How will that be impacted by a C++11 requirement?
>
> GCC 4.8 is needed for C++11 I think. There are folks using recent GDAL on older distros like
> Ubuntu 12.04 (which ships with gcc 4.6). I guess they could switch to adding a PPA with a
> more recent toolchain.

As a datapoint, NetBSD 6, a few years old but still supported, has gcc
4.5.  In general, it seems that requiring gcc 4.8 causes a fair bit of
grief for people.  I find that programs in straight C99 or older C++
build pretty much everywhere, and C++11 seems to take more effort.
Probably in 2 years this will be a non-issue.

Another possibility is to look at the features that would make a
difference and whether they are in boost.  As I somewhat fuzzily
understand it, much of the smart pointer stuff moved from boost to
C++11, so gcc 4.5 (or equivalent age clang) and boost may be a less
troublesome requirement.

Overall, I tend to think foundational support libraries should seek to
avoid being the thing that pushes someone to have to redo their
toolchain, and I am afraid that requiring C++11 would put gdal into that
category.

So, I think it's about how much trouble would be saved, vs imposed.   I
am not perceiving a lot of trouble from not using C++11 featues on the
dev list.

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev

signature.asc (167 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

Kurt Schwehr-2
Checking http://en.cppreference.com/w/cpp/compiler_support shows C++11 support starting to take shape starting with gcc 4.3 (but it's missing almost everything at that point).

Greg,

Can you explain the use case as to what keeps you on an older NetBSD but unable to use a branch of a recent GDAL?  e.g. I'm am suggesting that we keep GDAL 2.1 and older to stay with the current requirement of supporting C++03.

As for boost, my experiences are that would be far more effort support it on many platforms than getting a working C++11 compiler.  Boost is full of really awesome code, but there be dragons and really careful consideration should be made before requiring boost for any code that will have to be linked against by other libraries.

-kurt

On Thu, Jan 5, 2017 at 6:42 PM, Greg Troxel <[hidden email]> wrote:

Even Rouault <[hidden email]> writes:

>> How will that be impacted by a C++11 requirement?
>
> GCC 4.8 is needed for C++11 I think. There are folks using recent GDAL on older distros like
> Ubuntu 12.04 (which ships with gcc 4.6). I guess they could switch to adding a PPA with a
> more recent toolchain.

As a datapoint, NetBSD 6, a few years old but still supported, has gcc
4.5.  In general, it seems that requiring gcc 4.8 causes a fair bit of
grief for people.  I find that programs in straight C99 or older C++
build pretty much everywhere, and C++11 seems to take more effort.
Probably in 2 years this will be a non-issue.

Another possibility is to look at the features that would make a
difference and whether they are in boost.  As I somewhat fuzzily
understand it, much of the smart pointer stuff moved from boost to
C++11, so gcc 4.5 (or equivalent age clang) and boost may be a less
troublesome requirement.

Overall, I tend to think foundational support libraries should seek to
avoid being the thing that pushes someone to have to redo their
toolchain, and I am afraid that requiring C++11 would put gdal into that
category.

So, I think it's about how much trouble would be saved, vs imposed.   I
am not perceiving a lot of trouble from not using C++11 featues on the
dev list.

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev



--

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

Andrew C Aitchison-2
In reply to this post by Kurt Schwehr-2
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 ?

--
Andrew C Aitchison
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

Kurt Schwehr-2
Andres,

Have you tried compiling GDAL 1.11 as C++11?  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?

On Fri, Jan 6, 2017 at 12:50 AM, Andrew C Aitchison <[hidden email]> 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 ?

--
Andrew C Aitchison

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev



--

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

Andrew C Aitchison-2

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 <[hidden email]>
> 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 ?

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

Greg Troxel-2
In reply to this post by Kurt Schwehr-2

Kurt Schwehr <[hidden email]> writes:

> Greg,
>
> Can you explain the use case as to what keeps you on an older NetBSD but
> unable to use a branch of a recent GDAL?  e.g. I'm am suggesting that we
> keep GDAL 2.1 and older to stay with the current requirement of supporting
> C++03.

That is probably ok.  I should point out that I'm coming at this as a
packager - I look after a number of geo packages in pkgsrc, which
supports multiple versions of multiple operating systems, causing it to
run into more portability issues than packages for a particular Linux
distribution.  (My actual use of GDAL is so far not extensive and I can
certainly run it on a newer release.)

My concern is really that once there is a GDAL release that needs a
newer compiler, then some other program will require that version of
GDAL.  As a packager, I more or less have to decide whether to update
each program, balancing users getting new stuff and
stability/portability.

If no other packages start to depend on unreleased GDAL, and the first
GDAL release requiring C++11 is a ways off, and by then enough other
things require it that a system not having a C++11 compiler is totally
non-viable, then this shouldn't cause problems for pkgsrc.

> As for boost, my experiences are that would be far more effort support it
> on many platforms than getting a working C++11 compiler.  Boost is full of
> really awesome code, but there be dragons and really careful consideration
> should be made before requiring boost for any code that will have to be
> linked against by other libraries.

OK - thanks for explaining.

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev

signature.asc (167 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

Kurt Schwehr-2
Thanks Gred and Andrew!  Those are exactly the kind of comments that help.

Greg,

I have lots of experience packaging GDAL in fink for the mac, but less elsewhere.  I found this like which implies that pkgsrc is at GDAL 1.11.3.  Are there better links?


On Thu, Jan 12, 2017 at 8:57 AM, Greg Troxel <[hidden email]> wrote:

Kurt Schwehr <[hidden email]> writes:

> Greg,
>
> Can you explain the use case as to what keeps you on an older NetBSD but
> unable to use a branch of a recent GDAL?  e.g. I'm am suggesting that we
> keep GDAL 2.1 and older to stay with the current requirement of supporting
> C++03.

That is probably ok.  I should point out that I'm coming at this as a
packager - I look after a number of geo packages in pkgsrc, which
supports multiple versions of multiple operating systems, causing it to
run into more portability issues than packages for a particular Linux
distribution.  (My actual use of GDAL is so far not extensive and I can
certainly run it on a newer release.)

My concern is really that once there is a GDAL release that needs a
newer compiler, then some other program will require that version of
GDAL.  As a packager, I more or less have to decide whether to update
each program, balancing users getting new stuff and
stability/portability.

If no other packages start to depend on unreleased GDAL, and the first
GDAL release requiring C++11 is a ways off, and by then enough other
things require it that a system not having a C++11 compiler is totally
non-viable, then this shouldn't cause problems for pkgsrc.

> As for boost, my experiences are that would be far more effort support it
> on many platforms than getting a working C++11 compiler.  Boost is full of
> really awesome code, but there be dragons and really careful consideration
> should be made before requiring boost for any code that will have to be
> linked against by other libraries.

OK - thanks for explaining.



--

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

Nyall Dawson
In reply to this post by Greg Troxel-2
On 13 January 2017 at 02:57, Greg Troxel <[hidden email]> wrote:
>
> Kurt Schwehr <[hidden email]> writes:
>
> If no other packages start to depend on unreleased GDAL, and the first
> GDAL release requiring C++11 is a ways off, and by then enough other
> things require it that a system not having a C++11 compiler is totally
> non-viable, then this shouldn't cause problems for pkgsrc.
>

FYI - the upcoming QGIS 3.0 release has a hard c++11 requirement. Not
sure how much that affects things, but certainly projects which
utilise GDAL are already switching to c++11.

Nyall
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

Andrew Bell
There's a lot of code to work on.  Would it make sense just to make a C++11 branch and get to work, merging into master whenever it seems the right time?

On Thu, Jan 12, 2017 at 2:42 PM, Nyall Dawson <[hidden email]> wrote:
On 13 January 2017 at 02:57, Greg Troxel <[hidden email]> wrote:
>
> Kurt Schwehr <[hidden email]> writes:
>
> If no other packages start to depend on unreleased GDAL, and the first
> GDAL release requiring C++11 is a ways off, and by then enough other
> things require it that a system not having a C++11 compiler is totally
> non-viable, then this shouldn't cause problems for pkgsrc.
>

FYI - the upcoming QGIS 3.0 release has a hard c++11 requirement. Not
sure how much that affects things, but certainly projects which
utilise GDAL are already switching to c++11.

Nyall
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev



--
Andrew Bell
[hidden email]

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

Kurt Schwehr-2
That's a possibility, but as longs as we require most of the code base to work with C++03, merging is going to be miserable.  I'm suggesting we flip the requirement but make no immediate changes.  GDAL builds cleanly with C++11 and C++14 right now, so it's just a matter of flipping the requirement and then deciding what and when we allow things to switch to new C++11 idiums.  Initially, we can start by getting rid of ifdefs and doing a quick NULL -> nullptr (which is how gdal builds for me anyway with NULL defined to be nullptr).

On Thu, Jan 12, 2017 at 3:10 PM, Andrew Bell <[hidden email]> wrote:
There's a lot of code to work on.  Would it make sense just to make a C++11 branch and get to work, merging into master whenever it seems the right time?

On Thu, Jan 12, 2017 at 2:42 PM, Nyall Dawson <[hidden email]> wrote:
On 13 January 2017 at 02:57, Greg Troxel <[hidden email]> wrote:
>
> Kurt Schwehr <[hidden email]> writes:
>
> If no other packages start to depend on unreleased GDAL, and the first
> GDAL release requiring C++11 is a ways off, and by then enough other
> things require it that a system not having a C++11 compiler is totally
> non-viable, then this shouldn't cause problems for pkgsrc.
>

FYI - the upcoming QGIS 3.0 release has a hard c++11 requirement. Not
sure how much that affects things, but certainly projects which
utilise GDAL are already switching to c++11.

Nyall
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev



--
Andrew Bell
[hidden email]

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev



--

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

Greg Troxel-2
In reply to this post by Kurt Schwehr-2

Kurt Schwehr <[hidden email]> writes:

> Thanks Gred and Andrew!  Those are exactly the kind of comments that help.
>
> Greg,
>
> I have lots of experience packaging GDAL in fink for the mac, but less
> elsewhere.  I found this like which implies that pkgsrc is at GDAL 1.11.3.
> Are there better links?

Yes, it's behind, for no good reason.  I need to update it.  I might
have tried and found it non-trivial, but I don't remember clearly.

> - http://pkgsrc.se/geography/gdal-lib

That's a good link. Canonical http pointer at:
   http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/geography/gdal-lib/

Also, this shows build status on a lot of platforms (but a small
fraction of the set pkgsrc is intended to work on):

  https://bulktracker.appspot.com/pkgresults/geography/gdal-lib

> - https://github.com/joyent/pkgsrc/blob/trunk/geography/gdal-lib/Makefile

That's a soft fork, intending to have a few diffs but not much.  The
vast majority of things are the same, especially normal packages like
gdal-lib.




_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev

signature.asc (167 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

Jürgen E. Fischer
In reply to this post by Nyall Dawson
Hi,

On Fri, 13. Jan 2017 at 06:42:26 +1000, Nyall Dawson wrote:
> FYI - the upcoming QGIS 3.0 release has a hard c++11 requirement. Not
> sure how much that affects things, but certainly projects which
> utilise GDAL are already switching to c++11.

We're not using the C++ API - so that shouldn't matter.


Jürgen

--
Jürgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
Dipl.-Inf. (FH)             Rheinstraße 13          Fax. +49-4931-918175-50
Software Engineer           D-26506 Norden             http://www.norbit.de
QGIS release manager (PSC)  Germany                    IRC: jef on FreeNode                        

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev

attachment0 (844 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++11 timeline

Damian Dixon
In reply to this post by Greg Troxel-2
Hi,

We are actively using GDAL on WIndows, Linux and Android to deal with GIS data reading gaps.

Currently we are constrained to using 'gcc 4.7' on Linux, which gives us a lot of C++11 that we currently want to use.

On Windows we have switched to Visual Studio 2015.

On Android we will probably use the latest.

One of the reasons we tend to lag on compilers is due to needing to support customers on older Operating Systems as well as the usual reluctance to upgrade a compiler because of knock-on to system test costs.

That's not to say don't use new features of C++ or the library, just bear in mind the potential knock on.

One of the ways we have dealt with this potential knock-on is to use boost to provide many of the missing library features we are using.

We switch based on cmake tests between boost and the supplied libraries.

We have found the following very helpful from C++11 (and older):
  • shared_ptr
  • unique_ptr
  • nullptr
  • unordered_map
  • std::thread
  • std::nothrow for memory allocation
shared_ptr and unique_ptr make the management of allocated memory so much less error prone, so the use internally, even if the API is not changed, would be a bonus.

To be honest, if needed, we will just update the compilers we use to the minimum required.

Regards
Damian



On 13 January 2017 at 01:55, Greg Troxel <[hidden email]> wrote:

Kurt Schwehr <[hidden email]> writes:

> Thanks Gred and Andrew!  Those are exactly the kind of comments that help.
>
> Greg,
>
> I have lots of experience packaging GDAL in fink for the mac, but less
> elsewhere.  I found this like which implies that pkgsrc is at GDAL 1.11.3.
> Are there better links?

Yes, it's behind, for no good reason.  I need to update it.  I might
have tried and found it non-trivial, but I don't remember clearly.

> - http://pkgsrc.se/geography/gdal-lib

That's a good link. Canonical http pointer at:
   http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/geography/gdal-lib/

Also, this shows build status on a lot of platforms (but a small
fraction of the set pkgsrc is intended to work on):

  https://bulktracker.appspot.com/pkgresults/geography/gdal-lib

> - https://github.com/joyent/pkgsrc/blob/trunk/geography/gdal-lib/Makefile

That's a soft fork, intending to have a few diffs but not much.  The
vast majority of things are the same, especially normal packages like
gdal-lib.




_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
12
Loading...