[FFmpeg-devel] [PATCH] MMX for Win64

[Michael Niedermayer]

On Wed, May 07, 2008 at 12:14:46PM +0100, M?ns Rullg?rd wrote:
> 
> 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.

Its quicker if you do not know that it is a struct and want to know if it is
a struct. If you do know that it is a struct the extra "struct" slows you
down.

Most of the time IMO you either 
* do know its a struct already
* do not care at all
* need to know more than just if its a struct or not.

Really IMO knowing that something is a struct but not knowing anything else
is hardly usefull. Even the example with a small stack and stack overflow
is no good. An AVRational which is a struct is just 2 ints that has no problem
on the stack. Also an AVPacket is small and could easily be on the stack while
MpegEncContext should probably not be on the stack.

and besides
(AVRational) {1,2};
is more readable than
(struct AVRational) {1,2};

What one IMO should do is choose good descriptive names
AVRational  (rational is a/b thus a struct)
ABCDContext (context is obviously struct)

The extra struct seems to only help if you choose really bad names.

I cant help but the whole reminds me of hungarian notation ...

Also the last disadvantage listed at wiki about hungarian notation seems
somewhat appropriate here:
"Most of the time, knowing the use of a variable implies knowing its type.
Furthermore, if you don't know what a variable is used for, knowing its
type won't help you."

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080507/2c5560d4/attachment.pgp>