Main Content

AUTOSAR C++14 Rule M10-2-1

All accessible entity names within a multiple inheritance hierarchy should be unique

expand all in page

Description

Rule Definition

All accessible entity names within a multiple inheritance hierarchy should be unique.

Rationale

Data members and nonvirtual functions within the same inheritance hierarchy that have the same name might cause developer confusion. The entity the developer intended for use might not be the entity the compiler chooses. Avoid using nonunique names for accessible entities within a multiple inheritance hierarchy.

Polyspace Implementation

This checker flags entities from separate classes that belong to the same derived class if they have an ambiguous name. The name of an entity is ambiguous if:

  • Two variables share the same name, even if they are of different types.

  • Two functions share the same name, same parameters, and the same return type.

If the data member accessed in the derived class is ambiguous, Polyspace® reports this issue as a compilation issue, not a coding rule violation. The checker does not check for conflicts between entities of different kinds such as member functions against data members.

Troubleshooting

If you expect a rule violation but Polyspace does not report it, see Diagnose Why Coding Standard Violations Do Not Appear as Expected.

Examples

expand all

#include <iostream>
#include <cstdlib>
#include <cstdint>

using namespace std;

class A {
  public:
    int32_t num;               
    int32_t total;             
    int32_t sum(int32_t toSum) 
    {
        total = toSum + num;
        return total;
    };
};

class B {
  public:
    int32_t num;   //Also in class A
    int32_t total();           
    int32_t sum(int32_t toSum)   //Also in class A
    {
        num = toSum + num;
        return num;
    };
};


class C : public A, public B { //Noncompliant
  public:
    void foo() {
        num = total;
        sum(num);
    }
};

  • Because class A and class B define their own local variable int32_t num, and because class C is a multiple inheritance hierarchy containing class A and class B, Polyspace flags both int32_t num variables as noncompliant.

  • Because int32_t sum() in class A and int32_t sum() in class B share the same name, return type, arguments, and are members of the same multiple inheritance hierarchy, both functions are flagged by Polyspace as noncompliant.

  • Because int32_t total and int_32t total() are different types of class members, Polyspace does not flag them even though they are part of the same multiple inheritance hierarchy.

The ambiguous data members might be reported as compilation issues.

Because templates generate code, a class hierarchy deriving from a template might have nonunique names. In this example, the classes Deriv1 and Deriv2 derives from two separate instances of the template myObj. Then, the class FinalDerived derives from both Deriv1 and Deriv2. The template myObj generates two version of the function get() in the FinalDerived class: one from the myObj<int> instance and one from the myObj<short> instance. The nonunique name might result in unexpected behavior. Polyspace reports a violation

template <typename T>
class myObj {
	//...
public:
	void get(void);                       
};

class Deriv1: public myObj<int> {
public:
	//...                            
};

class Deriv2: public myObj<short> {
public:
	//...             
};

class FinalDerived: public Deriv1, public Deriv2 { //Noncompliant

public:
	//...
};

Check Information

Group: Derived Classes
Category: Advisory, Automated

Version History

Introduced in R2019a

See Also

Topics