[XviD-devel] xvid (cvs-head) problem (ffmpeg+mplayer)

[Christoph Lampert]

On Mon, 24 Feb 2003, Edouard Gomez wrote:

> Christoph Lampert (chl at math.uni-bonn.de) wrote:
> > My suggestion is to either split up vlc_codes.h or move BITS-related
> > functions from motion_est.c to bitstream.c, etc...
> > What cannot be handled this way should get a unique header, e.g. xvid_XXX
> > like ffmpeg (often) using ff_XXX for global symbols. 
> 
> I have a third way :)
> 
> Let's group all tables in a common structure and then we export only the
> structured element. Then in code we can do a bunch of defines to access
> tables directly without the need for -> or . operators.

If that's as fast as without the additional level, then sure, why not. 


> Example:
> 
> /* table.h */
> 
> typedef struct
> {
>     int *firsttable;
>     int *secondtable;
> }xvid_tables_t;
> 
> /* table.c */
> static int local_firsttable[64];
> static int local_secondtable[64];
> 
> xvid_tables_t xvid_tables = {
>     local_firsttable,
>     local_secondtable,
> };
> 
> /* Then e.g. in motion_est.c */
> #define cbpy_tab xvid_tables.cbpy_tab

That I don't like. I mean, I don't like #defines 
which contain fixed variable names as prefix or suffix 
or modify them or anything. 

And where is the advantage of #defining cpby_tab 
as xvid_tabls.cbpy_tab over simply calling the 
table xvid_cbpy_tab and defining 
#define cbpy_tab xvid_cbpy_tab

if we really want to keep the code shorter? 


> This way we export only one symbol: xvid_tables, but we still have
> access to all tables. This is a trick i use to build RC modules that
> export only one structure that gives access to local functions.
> 
> What do you think about that ?

I like the idea, but I don't know if it's really simpler or better than 
using unique names.  I have nothing against exporting many symbols if the
names are unique... 

gruel