search

eclipse-iceoryx / iceoryx

Eclipse iceoryx™ - true zero-copy inter-process-communication
https://iceoryx.io
Apache License 2.0
1.65k stars 384 forks source link

C++14 #220

Closed marthtz closed 3 years ago

marthtz commented 4 years ago

Brief feature description

As described in CONTRIBUTING.MD we'd like to move on to support C++ 14.

Detailed information

What's holding us back?

elBoberido commented 4 years ago

At the moment, I think QCC 5.4 on QNX. But we might soon switch to QCC8. Then there would be nothing which prevents us to switch to C++14 🤞

mossmaurice commented 4 years ago

At the moment, I think QCC 5.4 on QNX. But we might soon switch to QCC8. Then there would be nothing which prevents us to switch to C++14 🤞

AFAIK QCC 5.4 already fully supports C++14. As it is based on GCC see https://gcc.gnu.org/projects/cxx-status.html#cxx14

orecham commented 4 years ago

Hard agree. Gimme auto in lambdas :P (and other goodies).

elBoberido commented 4 years ago

I'm the last one who wouldn't want to use C++14, but currently it seems there are some limitations for QCC 5.4.

It seems QNX is switching to QCC 8, so we would get propper C++14 support. In the end we also need to switch to C++14 if we want to be compliant with the AUTOSAR Adaptive platform. @budrus, @dkroenke, do you have more information about the compiler we need to support? Should we just switch to C++14?

elBoberido commented 4 years ago

QNX 7.1 with QCC 8.3 was released about 2 weeks ago https://blackberry.qnx.com/en/embedded-software/qnx-software-development-platform

MiaoDX commented 4 years ago

Hi, it seems that you are moving on to C++14, as one possible downstream user, our project will still stick to C++ in the foreseeable future. So, if the API/ABI/linking is compatible, we won't complain, if not, please consider making ver 1.0 C++11 -.-

Discussions on stackoverflow seems that I should not worry too much: Discuss 1 and Discuss 2

Looking forward to 1.0 ~

dejanpan commented 3 years ago

@elBoberido replying to https://github.com/eclipse/iceoryx/issues/220#issuecomment-669055820:

  1. I am not aware of any issues with the gcc compiler on QNX
  2. The most recent versions of QNX had these versions of gcc and libc++
    1. QNX SDP 7.0 => GCC 5.4 with libc++ 3.7.1
    2. QNX SDP 7.1 = > GCC 8.3 with libc++ 8.0

If we check the status of gcc and libc++ we indeed see that all C++14 features are implemented in the lowest of the above versions:

  1. https://gcc.gnu.org/projects/cxx-status.html#cxx14
  2. https://libcxx.llvm.org/cxx1y_status.html

QNX also has a certified version (QNX OS for Safety 2.2) https://backendnews.net/blackberry-qnx-adds-another-certification-to-its-embedded-software-portfolio/ but this one is also OK wrt the C++14.

For me there is no brainer that iceoryx should switch to C++14 (which meanwhile can actually not be called moder C++ anymore), not for the features (which are completely modest https://en.wikipedia.org/wiki/C%2B%2B14) but more because of all the bug fixes since the C++11.

elBoberido commented 3 years ago

@dejanpan totally agree @MiaoDX sorry for not replying that long. It somehow went under the radar. Additionally to what dejapan said, we are also introducing a C-API, so the absolute worst case would be to use that one instead of the C++ API @marthtz @budrus any objections from your side to switch in the near future, let's say in November?

dejanpan commented 3 years ago

The discussion that is slightly harder is whether iceoryx should switch to C++17.

For that I would like to give a perspective from the point of view of our company, Apex.AI, that is certifying ROS 2 (currently still written in C++ 14) according to ISO 26262 (ASIL-D).

For this discussion relevant are these simplified steps that happen on the code:

  1. Code is compiled with additional security and safety related compiler flags (e.g. -Werror=format-security, -Wcast-align, -pedantic, -Wunused, ...)
  2. Code is analysed with the Axivion static code analyser using Adaptive Autosar Coding Guidelines
  3. Code is analysed with the Vector Cast tool and the test coverage is computed for lines, functions, branches and MC/DC
  4. Architecture and the dependency structure of the code is analysed with Lattix Architect
  5. Control and data flows are analysed with the tool Understand
  6. Test stubs are (auto) created with VectorCast for the dependent units (system calls, ...)
  7. Unit tests are written in gtest
  8. The code is sanitized with the various sanitizers: https://clang.llvm.org/docs/index.html
  9. The code is cross-compiled for Embedded Linux and QNX on aarch64 architectures
    1. In the near-term future other POSIX-compliant RTOSes will be added
  10. We use the gcc and libc++ versions available on above RTOSes and which have been validated with the validation suites like this one: https://solidsands.com/supertest.
  11. Following back-ported features from C++17 are used: std::optional, std::variant, std::string_view, std::apply, polymorphic allocator
  12. The code undergoes performance testing using https://gitlab.com/ApexAI/performance_test
  13. The performance is analysed and tuned with the following tools: perf, heaptrack, valgrind, LTT-ng

For us to now decide whether we can switch to the newest version of C++ we need to consider if above RTOSes and tools support, in this case, C++17.

  1. QNX is OK because of what I said above and:
    1. https://gcc.gnu.org/projects/cxx-status.html#cxx17
    2. https://libcxx.llvm.org/cxx1z_status.html
  2. VxWorks also already listed C++17 support
  3. VectorCAST and Axivion both use the C++ front end from EDG (https://www.edg.com/c) and they stay current with the latest standards. EDG fully supports C++17 already, and work is underway to support C++20

What is unknown/show stopper:

  1. Adaptive Autosar Coding Guidelines for C++17 are not available yet
  2. Someone will have to create a toolchain file for the cross compilation on the ARM-based ECUs
  3. C++17 support in these tools: Lattix, Understand, LTT-ng (likely available)
  4. We do not know what is the willingness of the (automotive) customers to switch to C++17. So far everyone is set on C++14.
  5. For general consideration - are all dependencies already ported to C++17?

In conclusion: Apex.AI would be willing to switch to C++17 as soon as the Adaptive Autosar Coding Guidelines for C++17 will be available.

marthtz commented 3 years ago

QNX also has a certified version (QNX OS for Safety 2.2) https://backendnews.net/blackberry-qnx-adds-another-certification-to-its-embedded-software-portfolio/ but this one is also OK wrt the C++14.

Sounds good. QNX SDP 7 mentions ISO 26262 ASIL D for automotive and C++14 support. However, the "Revision List of the QNX OS for Safety (QOS)" lists the C++ Library as ASIL B? https://www.certipedia.com/fs-products/files/certificates/certificates_asi/2020/EZ/968_EZ_653_13_20/appendix/EZ_653_13_20_RL_2020-11-02_QOS_2_2.pdf

dejanpan commented 3 years ago

@marthtz that is correct. Which means that for ASIL-D applications that are using such ASIL B certified libc++ one will need to certify the used parts of the libc++ as in context of that application.