You might want to look at the discussion in these recent asyn pull requests.
<https://github.com/epics-modules/asyn/pull/127>https://github.com/epics-modules/asyn/pull/126
<https://github.com/epics-modules/asyn/pull/127><https://github.com/epics-modules/asyn/pull/126>https://github.com/epics-modules/asyn/pull/127
Requiring C++11 precludes the use of these operating systems:
- RHEL6/Centos6. Dectris still ships Pilatus detectors with RHEL6, and we must run the EPICS IOC on that machine. It is also the only OS available for the marCCD detectors that are still in wide use at the APS and elsewhere.
- vxWorks 6.9.4.1. This is used on all beamlines and the accelerator at the APS. We cannot use C++11 until vxWorks 7 is ported to all of the boards we use, and it is tested with EPICS.
- RTEMS 4.10. This is in the asyn Travis CI build, but I don't know how widely deployed it is, nor how difficult it is to upgrade to 5.
Mark
________________________________
From: Core-talk <core-talk-bounces at aps.anl.gov> on behalf of Timo Korhonen via Core-talk <core-talk at aps.anl.gov>
Sent: Friday, October 2, 2020 4:29 AM
To: EPICS Core Talk
Subject: C++ standards discussion
Colleagues,
We had recently (if you can still call that “recent”) some discussion about which C++ standards would be required/accepted/recommended. Would somebody be so kind and help me refresh my memory where we ended with the discussion?
I remember that we stated that C++11 (compiler/toolchain) will be a requirement for EPICS 7.1 onwards. But were there any statements about C++14, C++17, and further? Anything more concrete than “we are looking into the issue”?
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 the moment it seems to me to say that it is OK to use C++11 features. Code that is not strictly limited to ESS applications (e.g., modules that might be contributed to the community) should not use newer features until further notice – I think?
Then we have to see what we can support internally at ESS but that is another thing.
Timo
- Replies:
- Re: C++ standards discussion Ralph Lange via Core-talk
- References:
- C++ standards discussion Timo Korhonen via Core-talk
- Navigate by Date:
- Prev:
Re: C++ standards discussion Ralph Lange via Core-talk
- Next:
Re: C++ standards discussion Ralph Lange via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: C++ standards discussion Ralph Lange via Core-talk
- Next:
Re: C++ standards discussion Ralph Lange via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
|