If the names are ambiguous, the compiler should report the name clash and not generate arbitrary or unexpectedly resolved code. However, this ambiguity may not be obvious to a developer.


There is also a specific concern that if the member function is virtual, resolving the ambiguity by explicitly referencing the base class in effect removes the virtual behaviour from the function.


== Noncompliant Code Example

----
class B1
{
public:
 int32_t count; // Noncompliant
 void foo ( ); // Noncompliant
};

class B2
{
public:
  int32_t count; // Noncompliant
  void foo ( ); // Noncompliant
};

class D : public B1, public B2
{
public:
  void Bar ( )
  {
    ++count; // Is that B1::count or B2::count?
    foo ( ); // Is that B1::foo() or B2::foo()?
  }
};
----


== Exceptions

For the purposes of this rule, visible function identifiers that form an overload set shall be considered as the same entity.


== See

* MISRA {cpp}:2008, 10-2-1 - All accessible entity names within a multiple inheritance hierarchy should be unique.


ifdef::env-github,rspecator-view[]
'''
== Comments And Links
(visible only on this page)

include::comments-and-links.adoc[]
endif::env-github,rspecator-view[]
