Main Content

AUTOSAR C++14 Rule A7-3-1

All overloads of a function shall be visible from where it is called

expand all in page

Description

Rule Definition

All overloads of a function shall be visible from where it is called.

Rationale

If all overloads of a function are not visible, a developer or code reviewer might expect an incorrect overload when a function is called. For instance, suppose a using declaration occurs between the definitions of two overloads of a function validateInput():

namespace initialTests {
    void validateInput(uint16_t input);
}

using initialTests::validateInput;

namespace initialTests {
    void validateInput(uint32_t input); //Noncompliant
}
When the function validateInput() is called, only the overload that occurs before the using declaration is in scope for call resolution. However, a developer might expect both overloads to be in scope and pick the incorrect overload.

Polyspace Implementation

The rule checker reports a violation in only one of two cases identified in the rule specifications:

  • The checker reports a violation if a function is declared in a namespace after these two events:

    1. Another overload of the function has been previously declared in the same namespace.

    2. A using declaration has already exposed that name to function call resolution.

  • The checker does not report a violation when an implementation of a function in a derived class hides the base class implementation of the same function.

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 <cstdint>

namespace initialTests {
    void validateInput(uint16_t input);
}

using initialTests::validateInput;

namespace initialTests {
    void validateInput(uint32_t input); //Noncompliant
}

namespace periodicTests {
    void validateResults(uint16_t results);
    void validateResults(uint32_t results); //Compliant
}

using periodicTests::validateResults; 

void main() {
    validateInput(0U);
    validateResults(0U);
}

In this example:

  • The declaration of validateInput(uint32_t) in the namespace initialTests violates the rule because the name validateInput from this namespace has already been exposed with an using declaration. This second declaration of validateInput() can cause developer confusion. For instance, the call to validateInput() in main invokes validateInput(uint16_t) but a developer might expect validateInput(uint32_t) to be invoked because it is a better match for the call.

  • The declarations of validateResults() in the namespace periodicTests do not violate the rule because both declarations appear before the using statement. When the function validateResults() is called, all overloads of validateResults() are exposed to name lookup. A developer can use only the parameters of validateResults() in the overload declarations to decide which overload is invoked, thereby reducing chances of confusion.

Check Information

Group: Declaration
Category: Required, Automated

Version History

Introduced in R2019a

See Also

Topics