[geos-devel] C++14

Greg Troxel gdt at lexort.com
Thu Dec 13 09:15:25 PST 2018


Daniel Baston <dbaston at gmail.com> 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.


More information about the geos-devel mailing list