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