Re: [PATCH 1/2] Fix sorting of enum values in FlagEnumerationPrinter

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2016-01-19 06:02, Pedro Alves wrote:
> Thanks for catching this.
> 
> I find it surprising that the printer doesn't respect the
> order of the values as they're defined though.  Shouldn't we
> remove the sort line entirely, thus keeping the
> existing behavior?  I couldn't find mention of the sorting
> in the documentation either.
> 
> Or, maybe the printer doesn't work correctly if the "overlapping"
> value (which I think it the whole point of this printer) is defined
> before the particular values, like, e.g.:
> 
>  enum flag_enum
>    {
>      ALL = 1 | 2 | 4,
>      FLAG_2 = 2,
>      FLAG_3 = 4,
>      FLAG_1 = 1,
>    };
> 
> ?

If we don't sort the values and ALL is defined first, then 0x7 will be
displayed as ALL instead of FLAG_1 | FLAG_2 | FLAG_3.  I don't think
either is wrong, we just don't know which one each particular user
would prefer.  So I think we can choose one way (sorted order, or
definition order) and stick with it.

Personally, I think I would prefer the more explicit version
(FLAG_1 | FLAG_2 | FLAG_3), which means keeping the sort.

> On 01/19/2016 04:23 AM, Simon Marchi wrote:
> 
>> +
>>  enum flag_enum
>>    {
>> -    FLAG_1 = 1,
>> +    /* Define the enumration values in an unsorted manner to verify 
>> that we
>> +       effectively sort them by value.  */
> 
> typo: "enumration".

Fixed.