On 4 May 2017 at 16:39, Martin Sebor <msebor@xxxxxxxxx> 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