Re: [gdal-dev] C++11 timeline

[Jürgen E . Fischer]

Hi Greg,

On Fri, 13. Jan 2017 at 19:15:27 -0500, Greg Troxel wrote:
> > We're not using the C++ API - so that shouldn't matter.
 
> I took the comment to mean that since QGIS would require c++11, if you
> wanted to run QGIS, you'd ned to cope with a new-enough compiler, in
> which case GDAL also needing it would not be an incremental burden.

Well, it just meant that we use the C API and therefore are not tied to use the
same compiler for GDAL and QGIS.


Jürgen

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


pgpLPxj3cHWav.pgp
Description: PGP signature
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] C++11 timeline

[Greg Troxel]

Jürgen E. Fischer  writes:

> 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.

I took the comment to mean that since QGIS would require c++11, if you
wanted to run QGIS, you'd ned to cope with a new-enough compiler, in
which case GDAL also needing it would not be an incremental burden.


signature.asc
Description: PGP signature
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] C++11 timeline

[Damian Dixon]

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  wrote:

>
> Kurt Schwehr  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
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] C++11 timeline

[Jürgen E . Fischer]

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)  GermanyIRC: jef on FreeNode 



pgpUvBPPX7wNa.pgp
Description: PGP signature
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] C++11 timeline

[Kurt Schwehr]

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 
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 
> wrote:
>
>> On 13 January 2017 at 02:57, Greg Troxel  wrote:
>> >
>> > Kurt Schwehr  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
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
>
> --
> Andrew Bell
> andrew.bell...@gmail.com
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
--
http://schwehr.org
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] 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 
wrote:

> On 13 January 2017 at 02:57, Greg Troxel  wrote:
> >
> > Kurt Schwehr  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
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
Andrew Bell
andrew.bell...@gmail.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] C++11 timeline

[Nyall Dawson]

On 13 January 2017 at 02:57, Greg Troxel  wrote:
>
> Kurt Schwehr  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
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] C++11 timeline

[Kurt Schwehr]

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?

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

On Thu, Jan 12, 2017 at 8:57 AM, Greg Troxel  wrote:

>
> Kurt Schwehr  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.
>



-- 
--
http://schwehr.org
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] C++11 timeline

[Greg Troxel]

Kurt Schwehr  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.


signature.asc
Description: PGP signature
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [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 
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
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] C++11 timeline

[Kurt Schwehr]

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 
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
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
--
http://schwehr.org
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] C++11 timeline

[Andrew C Aitchison]

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
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] C++11 timeline

[Jeff McKenna]

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
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] 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  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:
>
> http://en.cppreference.com/w/cpp/compiler_support
> https://en.wikipedia.org/wiki/List_of_compilers#C.2B.2B_compilers
>
> 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 
> 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
>>
>
>
>
> --
> --
> http://schwehr.org
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
Andrew Bell
andrew.bell...@gmail.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] C++11 timeline

[Kurt Schwehr]

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:

http://en.cppreference.com/w/cpp/compiler_support
https://en.wikipedia.org/wiki/List_of_compilers#C.2B.2B_compilers

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 
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
>



-- 
--
http://schwehr.org
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] C++11 timeline

[Even Rouault]

> 
> 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
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] C++11 timeline

[Howard Butler]

> On Jan 5, 2017, at 9:08 AM, Kurt Schwehr  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  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
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] C++11 timeline

[Kurt Schwehr]

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  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
>
>


-- 
--
http://schwehr.org
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] C++11 timeline

[Kurt Schwehr]

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
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev