19-12-2025, 01:04 PM
In effect, yes, code should be compiled as C++17.
If you want to continue to use C++14, then 4.1.1 must be deviated.
The justification for the deviation needs to consider:
- there may be rules that require the use of C++17 features, that obviously won't compile under C++14
- there are rules we removed because the behaviour they are trying to prevent is no longer possible in C++17
The first category is easy to spot, the code won't compile.
The second is more challenging, e.g. C++17 changed sequence point analysis so code that had UB in C++14 is well defined in C++17. If we were writing the rules for C++14 we'd have added a rule to prevent the UB.
You may have to do a gap analysis between AUTOSAR C++14 and MISRA C++:2023, to identify where there are significant issues that are not covered.
If you want to continue to use C++14, then 4.1.1 must be deviated.
The justification for the deviation needs to consider:
- there may be rules that require the use of C++17 features, that obviously won't compile under C++14
- there are rules we removed because the behaviour they are trying to prevent is no longer possible in C++17
The first category is easy to spot, the code won't compile.
The second is more challenging, e.g. C++17 changed sequence point analysis so code that had UB in C++14 is well defined in C++17. If we were writing the rules for C++14 we'd have added a rule to prevent the UB.
You may have to do a gap analysis between AUTOSAR C++14 and MISRA C++:2023, to identify where there are significant issues that are not covered.
Posted by and on behalf of
the MISRA C++ Working Group
the MISRA C++ Working Group