https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109740
Hermann Voßeler <prg at ichthyostega dot de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |prg at ichthyostega dot de
--- Comment #8 from Hermann Voßeler <prg at ichthyostega dot de> ---
I'd like to add an interesting twist to the discussion, which may help to shed
some light on the question if / when this warning is given adequately.
- We have template-generated handler code.
- the interface itself is assembled from several mix-in templates
- the implementation is build as a chain from several implementation
templates, which typically take the base class as template parameter
to inherit from, and one or two additional template parameters
- all those implementation templates add a concrete implementation
of a virtual function for some type given as parameter, and always *private*
- the sole purpose of the "exercise" is to generate a VTable. That means,
we'll place that implementation into some memory manager, and then forget
about the actual implementation type ("erase it").
- the actual calls will happen from a generic(templated) front-End, through
the generated interface.
Now, this warning triggers on each instantiation of those implementation
building blocks.
However, given the situation
- it will never be even possible to invoke the function through that type /
context where the warning is given, because that type is not captured /
retained and the virtual function is private.
- it is not possible to use the recommended workaround, because it is
not possible to bring the inherited other overloads into scope. Simply,
because they are also private in the preceding implementation template
- and even if we make all those implementations public, it is still not
possible to bring in the other overloads, since the functions in the
generated
interface are likewise inherently ambiguous. (They are not ambiguous for the
actual usage, because this actual invocation happens from a templated
front-end
into the interface, and then the call can be easily resolved)
The only solution is to use the _Pragma in one of the base headers, which
unfortunately
switches off the warning for lots of further code that happens to include this
header.
So this is not what anyone wants.
==> INSIGHT / CONCLUSION
It is problematic that this warning is given when the template is
*instantiated*.
It should be given when the actual (and potentially ambiguous or even
ill-guided)
call is happening.
That is, the compiler warns when a scope is created, which /could potentially/
lead
to a problematic overload resolution in combination with an automated
conversion.
But in the case I described and several other cases described in this comment
thread,
such a problematic call situation can not actually happen, and thus there is no
need for a preliminary warning.
I might be misinterpreting the situation, but to my understanding...
- the compiler actually performs the overload resolution
- the compiler actually collects the candidates to participate
- the compiler at that point actually checks, if virtual functions
from an inherited scope should be added to those candidates
Which means *at that point* the compiler would have all information
to give a really spot-on warning.
