Welcome, Guest
You have to register before you can post on our site.

Username
  

Password
  





  Rule 15.1.2
Posted by: Merge - 19-02-2026, 01:33 PM - Forum: 4.15 Special member functions - Replies (1)

Hi,

We are having a discussion internally about how to interpret rule 15.1.2. In particular, the rule exception says that a class is considered empty "when it has [...], no virtual member functions, [...]".
The question is whether a virtual (defaulted) destructor is considered a virtual member function in this context. For example, whether the following class is considered empty or not for the sake of this rule:


Code:
struct Base () {
    virtual ~Base() = default;
};

My personal interpretation is that this class is not considered empty (it will contain the v-table), so it does not qualify as an exception w.r.t. rule 15.2 when used as a base class. Can you confirm that this interpretation is correct?

Thank you very much and b
est regards,
Daniel "Merge" Merget

Print this item

  Rule 6.7.1 and local declarations with external linkage
Posted by: karos - 27-01-2026, 03:26 PM - Forum: 4.6 Basic concepts - Replies (1)

Is this rule intended to apply to variable declarations of external linkage? For example:

Code:
int main()
{
    extern int var;
    var = 4;
}

'var' is declared at block scope, refers to an object of static storage duration and is not const-qualified. Hence, it appears to be non-compliant with this rule.

However, my feeling is that it does not really fit the rationale of the rule as it does not add persistent state to the function (this declaration cannot be a definition, so some definition of var must exist outside of main). One could argue that var is effectively not local to the function containing the declaration.

Can you please clarify?

PS: I'm aware that such code does not comply with other rules as well (e.g. 6.7.2).

Print this item

  15.1.4 potentially incomplete wording
Posted by: hahn - 16-01-2026, 01:09 PM - Forum: 4.15 Special member functions - Replies (1)

Hi,

For the following code, to the best of our knowledge, the C++ standard guarantees that m1 and m2 are both properly initialized when creating an object of type C ([class.base.init]p9 and [dcl.init]p7).

Code:
class M { M() {} };
class C {
  M m1;
  M m2[2];

  C() {}
};


However, being strict with the amplification given for rule 15.1.4, data member m2 cannot be considered initialized: neither is C() delegating, nor does m2 have a default member initializer, nor does it appear in the member initialization list, nor does its (array) type feature a constructor.
m1 is considered initialized as its type M has a constructor.

We think the code example should be compliant, but the rule amplification wording seems incomplete.
Can you confirm this interpretation or do we miss a reason for this code to be non-compliant w.r.t. 15.1.4?

Thanks in advance!

Print this item

  Distinction between rule 6.8.1 and 6.8.4
Posted by: hahn - 15-01-2026, 10:41 AM - Forum: 4.6 Basic concepts - Replies (2)

Hi,

rule 6.8.4 covers a decidable subset of rule 6.8.1.
The scope of rule 6.8.4 is limited by the phrase "explicitly designates".
I am not sure about the exact meaning of "explicitly designates" and I hope for a clarification.

Here is a list of cases I am not sure about.
I put my interpretation of "explicitly designates" as comments in the code.

Code:
struct A {
  int m_a;
  int m_b;

  const int &a() const { // non-compliant - m_a as subobject explicitly designated
    return m_a;
  }
 
  const int &b() const { // compliant as rule does not apply? Or is ++m_a an explicit designation of subobject m_a?
    return ++m_a;
  }
 
  const int &c() const { // compliant as rule does not apply? Or is this expression an explicit designation of m_a/m_b too?
    return cond ? m_a : m_b;
  }
 
  const int &d() const { // compliant as rule does not apply? calling a() somehow designates m_a, but not "explicitly", right?
    return a();
  }

  const int *e() const { // compliant as rule does not apply as shown by examples for rule 6.8.4
    const int *p = &m_a;
    return p;
  }
};

All functions clearly violate the undecidable rule 6.8.1, but which functions should violate 6.8.4 too?

Thanks in advance.

Print this item

  4.1.1 Can MISRA C++:2023 be used with C++14 code?
Posted by: cgpzs - 16-12-2025, 10:26 AM - Forum: 4.4 General principles - Replies (1)

Rule 4.1.1 says code must comply with ISO C++ 17. Does this mean the code "must" be compiled with the -std=c++17 flag? Is there otherwise a good way to use MISRA C++:2023 on C++14 code (-std=c++14)? The motivation is to drop the AUTOSAR C++14 guidelines (which have been deprecated) and move to the more modern guidelines, while still keeping the standard used for compilation.

Print this item

  Rule 9.5.1 - Missing definitions
Posted by: cgpzs - 02-12-2025, 08:55 AM - Forum: 4.9 Statements - Replies (1)

Rule 9.5.1 talks about concepts like `init-statement`, `loop-counter`, etc which have not been defined anywhere in the document. `loop-counter` for example is a MISRA term and not a C++ Standard term.

The old MISRA C++:2008 rules did precisely define these concepts before they were used.

So I think MISRA C++:2023 should do the same.

Print this item

  Rule 7.0.2: Why the requirement for 'explicit' conversion operator?
Posted by: cgpzs - 27-11-2025, 09:04 AM - Forum: 4.7 Standard conversions - Replies (3)

Rule 7.0.2 has exceptions for "a class type having an explicit operator bool."

Question: why does the conversion operator have to be 'explicit' for the exception to apply? Even if the conversion operator is implicit, clearly the class was designed to be convertible to bool. This requirement seems therefore excessive.

I'm thinking for example about std::bitset::operator[] which returns a proxy object convertible to bool. However since the conversion operator is not explicit (as specified in the C++ standard), then even performing an explicit cast to bool from the proxy object violates Rule 7.0.2. 

Note: I am aware that the 'const' version of std::bitset::operator[] should return a 'bool' directly, but some implementations return the proxy object also here, so the conversion is still necessary.

Print this item

  Misra C++ 2023 14.1.1: clarify inherited members
Posted by: sks - 03-11-2025, 10:48 AM - Forum: 4.14 Member access control - Replies (1)

Hi everybody,

how should rule 14.1.1 handle inherited members, especially given the extra comment regarding "privileged access to data members".

For instance, consider

Code:
struct Base {
  int bm;
};

class Derived final : private Base {
private:
  int dm;
};

"Base" only has a single public member, thus is compliant.
"Derived" has a private member "dm" directly and another private member "bm" by inheritance. This is compliant I think.

However, what about public inheritance:
Code:
class Derived final2 : public Base {
private:
  int dm;
};

My assumption is that this now has a public and a private member and is thus non-compliant.

Can you please clarify:
- Are inherited members treated like non-inherited ones, taking into account the kind of inheritance?
- Does the additional note regarding derived classes requiring privileged acccess only refer to the discouraged usage of "protected" or should it enforce private members in class "Base" in case some derived class uses the member (ie. to avoid having to rely on private inheritance)?

Thanks for your help, regards

Sebastian

Print this item

  MISRA AC SLSF 2025 review
Posted by: david ward - 27-10-2025, 09:04 AM - Forum: MISRA AC SLSF discussions - No Replies

The MISRA AC working group is pleased to announce that updated drafts of its documents MISRA AC GMG and MISRA AC SLSF have been prepared. We will be conducting a public review of these drafts.

Review sign-up is now closed and we will be in touch shortly with those who have responded.

Print this item

  MISRA AC GMG 2025 review
Posted by: david ward - 27-10-2025, 09:04 AM - Forum: MISRA AC GMG discussions - No Replies

The MISRA AC working group is pleased to announce that updated drafts of its documents MISRA AC GMG and MISRA AC SLSF have been prepared. We will be conducting a public review of these drafts.

Review sign-up is now closed and we will be in touch shortly with those who have responded.

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,309
» Latest member: 1fuhd
» Forum threads: 1,066
» Forum posts: 2,933

Full Statistics

Online Users
There are currently 103 online users.
» 1 Member(s) | 98 Guest(s)
Applebot, Bing, Facebook, UptimeRobot, JillB

Latest Threads
13.2 Was TC2 correctly ap...
Forum: 8.13 Side effects
Last Post: misra-c
08-10-2026, 12:47 PM
» Replies: 1
» Views: 619
20.12 Does the stringific...
Forum: 8.20 Preprocessing directives
Last Post: misra-c
08-10-2026, 12:40 PM
» Replies: 1
» Views: 546
13.3 Should side effects ...
Forum: 8.13 Side effects
Last Post: misra-c
08-10-2026, 12:37 PM
» Replies: 1
» Views: 417
11.6 pointer to pointer t...
Forum: 8.11 Pointer type conversions
Last Post: misra-c
08-10-2026, 12:21 PM
» Replies: 2
» Views: 1,020
What is the UTLR of -1?
Forum: 8.10 The essential type model
Last Post: misra-c
08-10-2026, 12:15 PM
» Replies: 1
» Views: 588
10.3 Clarify if narrower ...
Forum: 8.10 The essential type model
Last Post: misra-c
08-10-2026, 11:57 AM
» Replies: 1
» Views: 497
It 8.12 intended to be so...
Forum: 8.8 Declarations and defnitions
Last Post: misra-c
08-10-2026, 11:50 AM
» Replies: 1
» Views: 442
Rule 0.1.1 Example f4
Forum: 4.0 Language independent issues
Last Post: cgpzs
07-10-2026, 11:07 AM
» Replies: 3
» Views: 709
Rule 6-2-2 Usage of std::...
Forum: 6.6 Statements (C++)
Last Post: misra cpp
25-09-2026, 05:43 PM
» Replies: 1
» Views: 428
M5-0-4 switch over unscop...
Forum: 6.5 Expressions (C++)
Last Post: misra cpp
25-09-2026, 01:00 PM
» Replies: 3
» Views: 515