C++14

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

C++14

Daniel Baston
Paul raised an issue yesterday about how to mark something as "deprecated" without using the "[[deprecated]]" attribute provided in C++14.

It made me wonder what others think about using C++14 for GEOS. I see C++14 as mostly a "bugfix" to C++11, introducing things like std::make_unique that were oddly omitted from C+11.

If we are going to modernize the code to use C++11, why not go straight to C++14? Are there major platforms that support C++11 but not C++14?

If you look at this chart, there is no release of gcc, clang, or MSVC that supports ALL of C++11 without also supporting ALL of C++14:

In all cases, you need gcc5, clang 3.8, or MSVC 19.0. (But yes, _most_ of C++11 is implemented in earlier releases of these.)

What do others think? One argument I can think of against this is that it complicates backporting of bugfixes.

Dan

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++14

Greg Troxel-2
Daniel Baston <[hidden email]> writes:

> Paul raised an issue yesterday about how to mark something as "deprecated"
> without using the "[[deprecated]]" attribute provided in C++14.
>
> It made me wonder what others think about using C++14 for GEOS. I see C++14
> as mostly a "bugfix" to C++11, introducing things like std::make_unique
> that were oddly omitted from C+11.

Perhaps, but the real issue is deployed compiler support.

> If we are going to modernize the code to use C++11, why not go straight to
> C++14? Are there major platforms that support C++11 but not C++14?
>
> If you look at this chart, there is no release of gcc, clang, or MSVC that
> supports ALL of C++11 without also supporting ALL of C++14:
> https://en.cppreference.com/w/cpp/compiler_support
>
> In all cases, you need gcc5, clang 3.8, or MSVC 19.0. (But yes, _most_ of
> C++11 is implemented in earlier releases of these.)

I think moving to C++14 is premature.  The real issue is that there are
a lot of systems out there, with various compilers, and there's an
implicit line between "too lame to cope" and "ok".  Right now, enough
things require C++11 that a system that can't build most C++11 is
nonviable.  This really means gcc 4.8 (or maybe 4.7; NetBSD went from
4.5 to 4.8 (and then to 5), so I don't know about 4.6 and 4.7).  It's
true that 4.8 does not fully support C++11, but it supports the parts
that almost all programs use.  The version that has 4.8 (7) is going to
drop out of support probably over the next year.  I think this is pretty
typical of systems that tend to stability rather than rapid tracking,
and would expect RHEL/CentOS to be the same or even more conservative in
updates.

If the base system compiler isn't new enough, then some gymnastics are
required.  This seems to be the case across a large class of systems,
including the various LTS types of releases.

I am starting to see more programs need C++14, but so far those are
relatively few and relatively giant and tend to be leaf packages, vs
things that if they don't build a very large number of packages are
broken.

This tends not to affect people that always update rapidly and use an OS
that rapidly adopts new compilers - which tend to tbe those contributing
to programs.  But the user community is I think pretty different, and
tends to upgrade more slowly, with larger numbers of installed systems.

So I think geos and similar things should wait until one can say with a
straight face "I don't understand your situation, your concerns, or your
constraints, but a system without a C++14 compiler is beyond lame and
therefore you don't matter".   I realize that's harsh, but that's
essentially what bumping compiler requirements does to people.    In a
year or two, enough other things will need it that people will have to
cope somehow.  So I guess I'm saying that geos is too foundational to be
on the list of why they have to cope now.
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++14

Paul Ramsey

> On Dec 13, 2018, at 9:15 AM, Greg Troxel <[hidden email]> wrote:
>  So I guess I'm saying that geos is too foundational to be
> on the list of why they have to cope now.

+1. We only just hopped to c+11, and we’re a library so there’s a lot of stuff resting on top. Taking it slow is a good idea.

P

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++14

Regina Obe
> > On Dec 13, 2018, at 9:15 AM, Greg Troxel <[hidden email]> wrote:
> >  So I guess I'm saying that geos is too foundational to be on the list
> > of why they have to cope now.
>
> +1. We only just hopped to c+11, and we re a library so there s a lot of stuff
> resting on top. Taking it slow is a good idea.
>
> P
>
> _______________________________________________
> geos-devel mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/geos-devel
[Regina Obe]
+1 for taking it slow.   I'm still shipping windows builds with GCC 4.8.3, though I plan to have completely moved to GCC 8.1 before 3.8 release.

I think a lot of packaging (for older systems I see) I see is still done on gcc 4.7.  Though one can argue that these older systems will not ship newer GEOS, so might not be so much of an issue aside from users who build their own GEOS stuck on old platforms.


Thanks,
Regina

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++14

Greg Troxel-2
"Regina Obe" <[hidden email]> writes:

> I think a lot of packaging (for older systems I see) I see is still
> done on gcc 4.7.  Though one can argue that these older systems will
> not ship newer GEOS, so might not be so much of an issue aside from
> users who build their own GEOS stuck on old platforms.

A good point for Linux, but in the non-Linux world (BSD, MacOS, Solaris, and
the rest of the vendor unix tradition) there is usually a notion of
"base system" and "packages or other stuff".  So with have things like
mv and the compiler in base, and then packages, the idea of wanting to
build newer packages with a not bleeding edge but not ancient compiler
(which describes gcc 4.8) is not really that strange.


_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++14

Kurt Schwehr-2
Getting people to be willing to drop support for old compilers is really difficult.  Especially without people who can provide strong support for older branches of all the related code bases.  A bunch of discussion went into the topic for these 2 RFCs...


C++14 isn't that huge of a jump and if there are features that people really want that are available in libs like abseil, it isn't unreasonable to port a copy into a private namespace of GEOS and use it until it can be refactored out when the minimum compiler make the standin irrelevant.  e.g. make_unique is here and could be converted to geos::private::make_unique or some such.


For deprecated, can just start with something simple like ABSL_DEPRECATED.  And drop it when you can.


On Thu, Dec 13, 2018 at 11:34 AM Greg Troxel <[hidden email]> wrote:
"Regina Obe" <[hidden email]> writes:

> I think a lot of packaging (for older systems I see) I see is still
> done on gcc 4.7.  Though one can argue that these older systems will
> not ship newer GEOS, so might not be so much of an issue aside from
> users who build their own GEOS stuck on old platforms.

A good point for Linux, but in the non-Linux world (BSD, MacOS, Solaris, and
the rest of the vendor unix tradition) there is usually a notion of
"base system" and "packages or other stuff".  So with have things like
mv and the compiler in base, and then packages, the idea of wanting to
build newer packages with a not bleeding edge but not ancient compiler
(which describes gcc 4.8) is not really that strange.


_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel


--

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++14

Vicky Vergara-2
More or less:

C++14 adds to C++11:

Relaxed constexpr constraints
Generic lambdas (e.g., [](auto p) { return p*2; })
Init-capture (e.g., [i = 2](auto p) { return p+i++; })
Variable templates
decltype(auto)
Deduced return types
Binary literals (e.g., 0b11101100)
Digit separators (e.g., 0b1110'1100)
Extend “aggregate class type” to include a class that would be a C++11 aggregate type if default member initializers were omitted
[[deprecated]] and [[deprecated("msg")]]

So the question is:
How much GEOS need those new features?
Its not using a lot of features of C++11 anyway

with c++ you can still use unique_ptr
I have a lot of (stalled) work in this branch
where the intention is to use more the unique_ptr and/or shared pointer
For example:

C++11 I think is good enough


On Thu, Dec 13, 2018 at 6:31 PM Kurt Schwehr <[hidden email]> wrote:
Getting people to be willing to drop support for old compilers is really difficult.  Especially without people who can provide strong support for older branches of all the related code bases.  A bunch of discussion went into the topic for these 2 RFCs...


C++14 isn't that huge of a jump and if there are features that people really want that are available in libs like abseil, it isn't unreasonable to port a copy into a private namespace of GEOS and use it until it can be refactored out when the minimum compiler make the standin irrelevant.  e.g. make_unique is here and could be converted to geos::private::make_unique or some such.


For deprecated, can just start with something simple like ABSL_DEPRECATED.  And drop it when you can.


On Thu, Dec 13, 2018 at 11:34 AM Greg Troxel <[hidden email]> wrote:
"Regina Obe" <[hidden email]> writes:

> I think a lot of packaging (for older systems I see) I see is still
> done on gcc 4.7.  Though one can argue that these older systems will
> not ship newer GEOS, so might not be so much of an issue aside from
> users who build their own GEOS stuck on old platforms.

A good point for Linux, but in the non-Linux world (BSD, MacOS, Solaris, and
the rest of the vendor unix tradition) there is usually a notion of
"base system" and "packages or other stuff".  So with have things like
mv and the compiler in base, and then packages, the idea of wanting to
build newer packages with a not bleeding edge but not ancient compiler
(which describes gcc 4.8) is not really that strange.


_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel


--
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel


--
Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky@georepublic.de
Web: https://georepublic.info

Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9

Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl


_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++14

Nyall Dawson
On Mon, 17 Dec 2018 at 04:08, Vicky Vergara <[hidden email]> wrote:

>
> More or less:
>
> C++14 adds to C++11:
>
> Relaxed constexpr constraints
> Generic lambdas (e.g., [](auto p) { return p*2; })
> Init-capture (e.g., [i = 2](auto p) { return p+i++; })
> Variable templates
> decltype(auto)
> Deduced return types
> Binary literals (e.g., 0b11101100)
> Digit separators (e.g., 0b1110'1100)
> Extend “aggregate class type” to include a class that would be a C++11 aggregate type if default member initializers were omitted
> [[deprecated]] and [[deprecated("msg")]]

There's also the very useful make_unique function.

But it's possible to "backport" make_unique to c++11, which is what we
do in QGIS: https://github.com/qgis/QGIS/blob/master/src/core/qgis.h#L357

Nyall



>
> So the question is:
> How much GEOS need those new features?
> Its not using a lot of features of C++11 anyway
>
> with c++ you can still use unique_ptr
> I have a lot of (stalled) work in this branch
> https://github.com/cvvergara/geos/tree/gPolygonizer
> where the intention is to use more the unique_ptr and/or shared pointer
> For example:
> https://github.com/cvvergara/geos/commit/f6c12cf17a40ddbe3b7e88b63728aac104ab8efa
>
> C++11 I think is good enough
>
>
> On Thu, Dec 13, 2018 at 6:31 PM Kurt Schwehr <[hidden email]> wrote:
>>
>> Getting people to be willing to drop support for old compilers is really difficult.  Especially without people who can provide strong support for older branches of all the related code bases.  A bunch of discussion went into the topic for these 2 RFCs...
>>
>> https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11
>> https://trac.osgeo.org/geos/wiki/RFC5
>>
>> C++14 isn't that huge of a jump and if there are features that people really want that are available in libs like abseil, it isn't unreasonable to port a copy into a private namespace of GEOS and use it until it can be refactored out when the minimum compiler make the standin irrelevant.  e.g. make_unique is here and could be converted to geos::private::make_unique or some such.
>>
>> https://github.com/abseil/abseil-cpp/blob/master/absl/memory/memory.h
>>
>> For deprecated, can just start with something simple like ABSL_DEPRECATED.  And drop it when you can.
>>
>> https://github.com/abseil/abseil-cpp/blob/master/absl/base/macros.h#L134
>>
>> On Thu, Dec 13, 2018 at 11:34 AM Greg Troxel <[hidden email]> wrote:
>>>
>>> "Regina Obe" <[hidden email]> writes:
>>>
>>> > I think a lot of packaging (for older systems I see) I see is still
>>> > done on gcc 4.7.  Though one can argue that these older systems will
>>> > not ship newer GEOS, so might not be so much of an issue aside from
>>> > users who build their own GEOS stuck on old platforms.
>>>
>>> A good point for Linux, but in the non-Linux world (BSD, MacOS, Solaris, and
>>> the rest of the vendor unix tradition) there is usually a notion of
>>> "base system" and "packages or other stuff".  So with have things like
>>> mv and the compiler in base, and then packages, the idea of wanting to
>>> build newer packages with a not bleeding edge but not ancient compiler
>>> (which describes gcc 4.8) is not really that strange.
>>>
>>>
>>> _______________________________________________
>>> geos-devel mailing list
>>> [hidden email]
>>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>>
>>
>> --
>> --
>> http://schwehr.org
>> _______________________________________________
>> geos-devel mailing list
>> [hidden email]
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
>
>
> --
>
> Georepublic UG (haftungsbeschränkt)
> Salzmannstraße 44,
> 81739 München, Germany
>
> Vicky Vergara
> Operations Research
>
> eMail: [hidden email]
> Web: https://georepublic.info
>
> Tel: +49 (089) 4161 7698-1
> Fax: +49 (089) 4161 7698-9
>
> Commercial register: Amtsgericht München, HRB 181428
> CEO: Daniel Kastl
>
> _______________________________________________
> geos-devel mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/geos-devel
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel