Why do you think you should be able to make it public, when you don't even
have the right to call it?

Your best bet is to override it, calling the best impl. This will create a
new function with whatever visibility you want.

On Mon, Jun 28, 2021 at 10:26 AM chuanqi.xcq via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hi,
>
> Recently I met a problem described as the title, here is the background.
>
> I am cleanning some codes with the warning of overloaded virtual functions.
> Here is the introduction for overloaded virtual functions:
>
> https://stackoverflow.com/questions/18515183/c-overloaded-virtual-function-warning-by-clang
>
> Simply, for the codes:
> ```
> struct Base
>
> {
> virtual void * get(char* e);// virtual void * get(char* e, int index);
> };
> struct Derived: public Base {
> virtual void * get(char* e, int index);
> };
>
> ```
>
> Compilers would complains about:
> ```
>
> warning: 'Derived::get' hides overloaded virtual function [-Woverloaded-virtual]
>
> ```
>
> And the corresponding suggestion is:
> ```
>
> struct Derived: public Base {
> using Base::get; // tell the compiler we want both the get from Base and ours
> virtual void * get(char* e, int index);
> };
>
> ```
>
> Then I use this method to refactor our codes and I run into problems with:
> ```
> struct Base {
> virtual void * get(char* e);
> private:
> virtual void * get(char* e, int index);
>
> };
> struct Derived: public Base {
>
> using Base::get; // Now the compiler complains that Base::get is private.
> virtual void * get();
> };
>
> ```
>
> At first, I thought it is a compiler bug. Since I think the compiler
> should search for the accessible part first.
>
> However, I find these words in 9.9.14 N4878,
> ```
>
> In a using-declarator that does not name a constructor, every declaration
> named shall be accessible.
> ```
>
> So the behavior of compiler is consistent with the standard. Then I want
> to ask,
> do you guys think it is a defect in the standard or there is any solution
> other than
> more aggresive refactoring?
>
> BTW, I send this to both std-discussion and std-proposal since I guess it
> is
> related to both. Remind me if anyone isn't comfortable.
>
> Thanks,
> Chuanqi
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>