On 29/07/17 23:12, Hendrik Leppkes wrote:
> On Sat, Jun 24, 2017 at 5:48 PM, Diego Biurrun <di...@biurrun.de> wrote:
>> On Sat, Jun 24, 2017 at 11:56:07AM -0300, James Almer wrote:
>>> On 6/23/2017 8:39 PM, Mark Thompson wrote:
>>>> --- a/libavcodec/h264.h
>>>> +++ b/libavcodec/h264.h
>>>> @@ -44,4 +44,49 @@ enum {
>>>> +
>>>> +enum {
>>>
>>> enum seems like a weird choice for this to be honest. Same with the
>>> following patch.
>>>
>>> What's wrong with using #define?
>
> I only saw this in the latest batch of the patch, so sorry for the
> late reply, and I found the use of an anonymous enum quite weird.
>
>>
>> Why would you want to use #defines when you can use an enum? What's wrong
>> with type safety? :)
>>
>
> There is no type safety here, since the type has no name.
>
> I didn't see any reason to prefer the enum, only why it isn't
> necessary to use a define. It smells quite odd to me, and unlike
> anything we use anywhere else.
> So whats the reasoning to use those?
I prefer it because it's actually a compiler constant rather than a text
substitution - you don't need to think about how it's expanded, with extra
parentheses. That also means that it is compile-tested when added, not when
first used. I think the only other significant difference is that it is not
accessible at preprocessor time for #if, but none of these constants will ever
want that.
If there is a consensus that these should be expanded by the preprocessor
instead then I can easily change it.
- Mark
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
