Support for C++17 as base standard of OpenBSW

[rolandreichweinbmw]

Currently, we support C++14 as the base C++ standard in OpenBSW, and ensure in the CI that OpenBSW works in projects based on C++ 17, 20, 23.

However, we can't use any new features generally from C++17 onwards.

I propose dropping C++14 and switch to C++17 to support new features from it.

This would:

• Simplify the checks for supporting OpenBSW on different C++ standards versions
• Enable us to use C++17 based tooling like newer MISRA checkers, e.g. MISRA++23 supporting C++17

Does anyone have a requirement to still support C++14 in their projects using OpenBSW? Or can we consequently drop C++14 support?

[rolandreichweinmusic]

When building the unit tests with google test, we currently get deprecation warnings from old cmake compatibility declarations.

Upgrading to new google test 1.17.x requires C++17.

[thomas-herrmann-1]

Just one example: Tasking VX-tool chain for Aurix TriCore TC2xx/TC3xx doesn't support or doesn't yet fully support C++17. And we really have bad experience with embedded tool chains promising to support a newer C++ standard with some latest version. And were then really happy to have a reliable tool support for some older standard at all. Yes, there are really nice features coming with newer standards. But for a library intending to be used on many embedded platforms I wouldn't put the minimum requirements too high.

[rolandreichweinbmw]

This depends on the answer to the question if OpenBSW is supposed to support old Tasking compilers for TriCore.

They are currently not supported by OpenBSW. Not only by a missing BSP (which admittedly a user of OpenBSW could implement privately) but the common code currently being dependent on ARM Cortex M4, e.g.

• platforms/s32k1xx/bsp/bspInterruptsImpl/include/interrupts/suspendResumeAllInterrupts.h
• libs/safety/safeWatchdog/src/safeWatchdog/SafeWatchdog.cpp
• ...

While the latter issue can be resolved by refactoring, the above point can be resolved by using another compiler supporting TC, e.g. LLVM.

All possible with C++17 :-)

[johannes-esr]

@rolandreichweinbmw, in my opinion supporting C++14 would be beneficial if there are (very) old toolchains used in some projects, but I get your point - let's take this discussion in our next OpenBSW meeting. Do you have in mind if any parts of OpenBSW could be simplified/dropped if we switch to C++17?

[rolandreichweinmusic]

Even if rumors suggested it, last time we asked for examples of relevant old toolchains with issues, none were reported.

Regarding C++17 features, Wikipedia has a good introductory list of many new features. My personal favorites are:

• nested namespaces a::b {}
• [[maybe_unused]]
• [[nodiscard]]
• constexpr if.

BTW: While we are at it, we can move from C99 to C17 as well. Will enable static_assert in C.

[johannes-esr]

Valid point - I added it to the agenda!

[filipe-cuim]

Would also like to add:

• constexpr lambda
• inline variables
• structured binding
• initializers for if and switch
• guaranteed copy-elision (important)
• [[fallthrough]]
• fold expressions

[dcavalei]

C++17 introduced improvements for meta-programing, for example constexpr if, which can substitute SFINAE, as mentioned before.
This is a big addition because it simplifies by a lot the implementation of some design patterns that can use templates. For example:
https://refactoring.guru/design-patterns/strategy

This is the difference between simple, concise, self-explanatory code, OR unneeded verbosity/keywords that do not add value to the code real purpose!

[christophruethingbmw]

Would also vote up for this, especially static constexpr inline members are nice to have.