[FFmpeg-devel] [PATCH] MMX for Win64

[Måns Rullgård]

Baptiste Coudurier wrote:
> M?ns Rullg?rd wrote:
>> Reimar D?ffinger wrote:
>>> On Wed, May 07, 2008 at 10:27:57AM +0100, M?ns Rullg?rd wrote:
>>>> Baptiste Coudurier wrote:
>>>>> M?ns Rullg?rd wrote:
>>>>>> There are good reasons not to use typedefs for structs (or pointers).
>>>>>> I avoid doing it in new code.
>>>>> Oh, can you please elaborate a little ? Im really interested in knowing why.
>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/CodingStyle;hb=HEAD#l270
>>>>
>>>> Extrapolate from there.
>>> Well, the thing that is the major claim, namely 'Lots of people think
>>> that typedefs "help readability". Not so.' is not exactly convincing.
>>> Luckily it's usually only one function argument that is a struct, but
>>> if only considering readability I find
>>>> int function(actx_t *a, bctx_t *b, cctx_t *c);
>>> much better than
>>>> int function(struct actx *a, struct bctx *b, struct cctx *c);
>>> because the "struct"s use up a lot of space without adding any useful
>>> information.
>>
>> But they do add information.
>
> Useless information IMHO, it is fairly obvious and quickly verifiable
> what "AVCodecContext" is.

My point is that explicitly using 'struct' removes the need for any
verification whatsoever, which must surely be quicker.

> AFAIK C++ even got rid of this by making
> "struct" optional in parameters/vars declarations.

They did, and they opened some really nasty traps in doing so.  I refuse
to touch anything C++ related.

>> A function argument of type pointer to int
>> is usually used to return a value, whereas a pointer to struct is commonly
>> used for both input and output values.  The point is, immediately seeing
>> that something is a struct, without searching for a definition, is often
>> helpful, especially to other people than the author of the code.
>
> Well If I follow your reasonment, you should agree to put comments for
> people not really knowing C, which explains exactly what the code does,
> after all they aren't the author of the code and it is helpful for other
> people:

Knowing C is one thing, knowing the internals of every programme/library
written in C is something entirely different.  Even a master of C is
helped by little clues like this.  Explaining the action of the ++
operator every time it's used is obviously something that should not be
done.

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