+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C++ (https://forum.misra.org.uk/forumdisplay.php?fid=18)
+--- Forum: AUTOSAR C++:2014 rules (https://forum.misra.org.uk/forumdisplay.php?fid=185)
+--- Thread: M9-3-3 and observable state (/showthread.php?tid=1615)
M9-3-3 and observable state - kth - 14-04-2022
The AUTOSAR Guidelines for the use of the C++14 language in critical and safety-related systems (Release 19-03/latest) basically reuse MISRA C++ Rule 9-3-3 as M9-3-3 but add two clarification notes and a reference to C++ Core Guidelines
- Con.2: By default, make member functions const.
The rationale of Con.2 explicitly uses "observable state":
Quote:Reason A member function should be marked const unless it changes the object’s observable state. This gives a more precise statement of design intent, better readability, more errors caught by the compiler, and sometimes more optimization opportunities.
Motivation of this post is that our static analysis tool currently reports a M9-3-3 finding for this code:
Code:
class B final {
public:
B(int* dest) : p_{dest} {}
int& Get() { return *p_; } // M9-3-3 reported
// Here adding const to Get() does not lead to a compiler error, due to the indirection that is introduced with
// the pointer 'p_'. However, adding const without changing the return type to 'const int&' is missleading.
private:
int val_{0};
int* p_{&val_};
};A similar example with shared_ptr:
Code:
class Data
{
public:
// changes the observable state
void Set(int val) noexcept
{
val_ = val;
}
int Get() const noexcept
{
return val_;
}
private:
int val_;
};
class WithSharedPtr {
public:
void SetValue() { //< M9-3-3 Method can be declared const reported here
sptr->Set(3);
}
void ChangePtr() {
sptr = std::make_shared<Data>();
}
int GetValue() const {
return sptr->Get();
}
private:
std::shared_ptr<Data> sptr = std::make_shared<Data>();
};For both findings adding const is technically possible, but the observable state is changed.
My question: what is the correct interpretation of MISRA C++ 9-3-3 and AUTOSAR M9-3-3?
RE: M9-3-3 and observable state - cgpzs - 20-04-2022
I had a very similar question:
https://forum.misra.org.uk/thread-1594-post-3496.html#pid3496
RE: M9-3-3 and observable state - kth - 20-04-2022
@cgpzs The answer provided with https://forum.misra.org.uk/thread-1594-p...ml#pid3496 was:
Quote:The rule as drafted was intended to just cover 'syntactic const', but we recognise that this has limitations.
In this case, you'll need to deviate, or artificially modify the function so that it cannot be made const.
That answers the "what is the correct interpretation of MISRA C++ 9-3-3" part of my question - thank you.
However, the AUTOSAR GuidelineM9-3-3 explicitly references Con.2, which is about observable state. Therefore, I think it is a legitime question to ask what is(/was) intended with M9-3-3 and in the future (MISRA C++ 202x).
I also think that the majority of developers that consult the C++ Core Guidelines will ask the question again when a static analysis tool reports a finding for code that changes the observable state (see my examples).
Frankly, I would welcome, if the next version of the MISRA C++ rules would contain an exception for code that violates the observable state - or at least a clarification concerning the differences to Con.2.
RE: M9-3-3 and observable state - misra cpp - 29-04-2022
As has been pointed out, this is a long standing issues.
We are addressing it for the next version.