Re: -Wenum-compare and template metaprogramming

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 4 May 2017 at 16:39, Martin Sebor <msebor@gmail.com> wrote:
> On 05/04/2017 05:10 AM, Jonathan Wakely wrote:
>>
>> On 4 May 2017 at 07:32, Xi Ruoyao wrote:
>>>
>>> On 2017-05-03 11:26 +0100, Jonathan Wakely wrote:
>>>>
>>>> On 3 May 2017 at 05:41, Xi Ruoyao wrote:
>>>>>
>>>>> In template metaprogramming, we may write something like
>>>>>
>>>>> ~~~~~
>>>>> template <typename A, typename B>
>>>>> struct BetterType
>>>>> {
>>>>>   typedef If<(Priority<A>::value > Priority<B>::value), A, B>::type
>>>>> type;
>>>>> };
>>>>> ~~~~~
>>>>>
>>>>> However, GCC -Wenum-compare (enabled by default) would complain
>>>>> at each POT of BetterType.  It seems annoying.
>>>>>
>>>>> Of course we can cast the operands of compare to int.  But should we
>>>>> make GCC more clever and not to complain this causal idiom?
>>>>
>>>>
>>>> You're comparing unrelated enumeration types, which is what the
>>>> warning is designed to warn about. Why should it not warn just because
>>>> it's in a template?
>>>
>>>
>>> No.  My point is, in this "enum hack" case we just use the enum values as
>>> integer constants, not because they are in templates.
>>>
>>> Maybe we could silence the warning for the enums has only one
>>> enumerator with assigned value.
>>
>>
>> I suppose it could, but that would mean we fail to warn in cases where
>> we should be warning e.g.
>
>
> If I understand the correctly the suggestion is to avoid warning
> for comparison of enumerators of different types (not objects of
> the enumerated types).

Ah good point. My example wasn't doing that.

> Assuming the code defines the enums as unnamed types, comparing
> their enumerators seems unlikely to be a problem.  Or can you
> think of some accidental misuse that the warning would detect?

I can't immediately think of any problem, except for encouraging the
hack, which I'm not fond of :-)

> If there isn't one it might to detect the (legacy) idiom and
> suppress the warning in that case.  Or add a warning suboption
> to control it, until the code transitions to the more modern
> way of doing things.  Or perhaps only warn in C++ 11 mode and
> later.
>
> Martin