[FFmpeg-cvslog] r12165 - trunk/libavcodec/dsputil.c

[Måns Rullgård]

Rich Felker <dalias at aerifal.cx> writes:

> On Thu, Feb 21, 2008 at 09:22:20AM -0700, Loren Merritt wrote:
>> On Thu, 21 Feb 2008, Rich Felker wrote:
>> 
>> > On Thu, Feb 21, 2008 at 08:56:40AM -0700, Loren Merritt wrote:
>> >>>> Modified: trunk/libavcodec/dsputil.c
>> >>>> ==============================================================================
>> >>>> --- trunk/libavcodec/dsputil.c	(original)
>> >>>> +++ trunk/libavcodec/dsputil.c	Thu Feb 21 08:54:46 2008
>> >>>> @@ -50,6 +50,9 @@ void ff_add_png_paeth_prediction(uint8_t
>> >>>>  uint8_t ff_cropTbl[256 + 2 * MAX_NEG_CROP] = {0, };
>> >>>>  uint32_t ff_squareTbl[512] = {0, };
>> >>>>
>> >>>> +static const unsigned long pb_7f = 0x7f7f7f7f7f7f7f7fUL;
>> >>>> +static const unsigned long pb_80 = 0x8080808080808080UL;
>> >>>
>> >>> Wouldn't it be faster to put these constants inline in the code
>> >>> instead of as 'static const'?
>> >>
>> >> gcc does that. Any value derivable at compile time is equivalent to an
>> >> inline constant.
>> >
>> > This is surely not traditional compiler behavior; if your intent is to
>> > have them inlined then preprocessor constants or literals are
>> > preferred.
>> 
>> Is constant propogation a recent invention?
>
> The const keyword in C is not as strong as in C++. Historically it was
> just a hint for warning generation and binary sectioning. C99
> (possibly also C90?) add some teeth but I think it's still iffy to
> consider const-qualified variables as real constants. They're not
> usable in certain contexts where a constant is required.

More precisely, a const-qualified variable is not a "constant
expression".  This makes it unusable, among other places, in
initialisers for objects with static storage duration and in case
labels.

-- 
M?ns Rullg?rd
mans at mansr.com