EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022 
<== Date ==> <== Thread ==>

Subject: Re: C++ standards discussion
From: "Konrad, Martin via Core-talk" <core-talk at aps.anl.gov>
To: Timo Korhonen <Timo.Korhonen at ess.eu>
Cc: EPICS core-talk <core-talk at aps.anl.gov>
Date: Fri, 2 Oct 2020 15:29:12 +0000
Hi Timo,
> I remember that we stated that C++11 (compiler/toolchain) will be a 
> requirement for EPICS 7.1 onwards.
Correct.

> But were there any statements about C++14, C++17, and further?
> Anything more concrete than “we are looking into the issue”?
Assuming that EPICS 7.1 will be released in the next 1-2 years it will
most likely not use any C++14 features. In contrast to C++11 most of the
C++14 features aren't that valuable to us. However, we would lose
support for a few older but still supported operating systems if we
would require C++14 (e.g. Ubuntu 16.04 "xenial" which is currently used
for our Travis builds and comes with GCC 5.3 which doesn't have full
C++14 support, yet). It remains to be seen if there will ever be an
EPICS release which states "C++14" as a requirement. VxWorks (which used
to hold us back) jumps from C++03 support in version 6 to a C++17
compatible toolchain in version 7. With that in mind I wouldn't be
surprised if EPICS 7.2 (?) would go straight to C++17 as well. Note that
all these statements are applying to EPICS Base. For other code in the
EPICS ecosystem requirements might be less strict.

> Why am I asking? We have many contributors in our (ESS)
> collaborating institutes, some of them very innovative 😉and we would
> like to give them some rules and guidelines when they write code for
> ESS and possibly wider purposes.
At FRIB we are leveraging modern C++ features (currently up to C++17)
for support modules and applications (which are mostly used at FRIB).
This saves development time on our end, helps with code quality and
allows us to leverage the latest libraries. In case others want to use
our code with older compilers they can backport it. Putting the burden
of doing so on them allows them to weigh the cost of backporting vs.
upgrading. With more and more modules benefiting from modern C++
features upgrading will become more and more attractive. It occasionally
might pay off to go with an older standards version in the hope of
getting community contributions from a larger user base. Overall it's
difficult to give general guidance here - you might need to decide on a
case-by-case basis.

Cheers,

Martin

-- 
Martin Konrad
Facility for Rare Isotope Beams
Michigan State University
640 South Shaw Lane
East Lansing, MI 48824-1321, USA
Tel. 517-908-7253
Email: konrad at frib.msu.edu

References:
C++ standards discussion Timo Korhonen via Core-talk

Navigate by Date:
Prev: Re: C++ standards discussion Ralph Lange via Core-talk
Next: ABI compatibility with different C++ standard versions Konrad, Martin via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022 
Navigate by Thread:
Prev: Re: C++ standards discussion Ralph Lange via Core-talk
Next: ABI compatibility with different C++ standard versions Konrad, Martin via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022 
ANJ, 07 Oct 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·