[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

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

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