cpp:S1242 - is this rule too "aggressive", or my understanding wrong?

[avl (Andreas L.)]

SonarQube 10.0 here - the message is: »Rename this member function so that it doesn’t hide an inherited non-virtual function, or make it virtual in the base class “SomeBaseClass”.«

SomeBaseClass has a (non-virtual) method taking one single argument.

Subclass inherits the named method, but also adds a same-named method, taking two arguments.

Now, SonarQube tells me, that this overload hides the inherited method.
Is this true? How could a method possibly “hide” a different-ary method?

If it is truly possible, I’d be grateful to learn about it, but otherwise, I think
that cpp:S1242 should be restricted to cases where hiding is actually possible.

PS: the compiler apparently picks the right overload… the affected program just works.

[JolyLoic (Loïc Joly)]

Hi @avl,

You can see in the following example (click here to see it in compiler explorer) that there can actually be hiding:

struct Base {
    int f();
};

struct Derived : public Base {
    int f(int i);
    int g() {
        return f(); // Error
    }
};

If you think it does not happen in your case, could you share with us a minimal example that reproduces the issue?

[avl (Andreas L.)]

Half way right…

I noticed that the call-site of my “hidden” method actually called it with “baseclass::” - now I know, why

Otoh, if the “hidden” function has a different “arity” than the hiding method, then the compiler would already reject any naive wrong calls (that is: any without baseclass-qualified calling) - so there isn’t much real danger pending, of what sonarqube would save me…

Am I missing something else?

[JolyLoic (Loïc Joly)]

Hi @avl,

It’s true that if the arity differs (even when taking into account default arguments, variadic functions,…), it’s not dangerous in the sense that the code would not compile, but it can still be surprising for the developer. This is why this rule is classified as a code smell.

I’m not sure what is your use-case, but would it work in your case to add a using-declaration in the derived class (see updated example)?

[avl (Andreas L.)]

Wow, this “using Base::f;” would have perfectly fit the bill… (I didn’t want to override it with just a call to baseclass method, and I wasn’t aware of that C++ feature)

In the meantime, however, I just renamed one of the methods.

[JolyLoic (Loïc Joly)]

You are right that we don’t mention this possibility enough in the rule description. I created a ticket to mention it more prominently.