Chris LaVelle wrote:
> in the header...
> typedef struct XXX_ELEMENT_tag
> {
> UINT8 num;
> UINT8 param;
> UINT16 fre1;
> INT16 a1;
> } ;
It makes no sense to have "typedef" in the above.
> typedef struct XXX_ELEMENT_tag ELEMENT_T;
If you were goint to use a typedef, then this should be combined with
the above:
typedef struct XXX_ELEMENT_tag
{
UINT8 num;
UINT8 param;
UINT16 fre1;
INT16 a1;
} ELEMENT_T;
> #define MAX_ELEMENTS 8
> typedef struct XYZ_S_tag {
> UINT8 num_elements;
> UINT8 flag;
> ELEMENT_T element[MAX_E]; /*** This is the spot ***/
> } XYZ_S_tag;
Please try keep posted code actually compilable. Are MAX_ELEMENTS and
MAX_E different things?
> And of course the S_tag structure is buried one more structure down. Say
> something like:
>
> typedef struct T_TABLE_tag
> {
> XYZ_S_tag run;
> XYZ_S_tag walk;
> .... /* alot of these */
> XYZ_S_tag crawl;
> } TABLE_T;
> typedef struct T_TABLE_tag T_table;
What's the use for two typedef names for the same struct? And if you
really want them, why waste an entire second typedef statement for the
job?
typedef struct {
} Name1, Name2;
works just as well.
> And in a C file a global is initialized like this...
> T_table t_table =
> {
> { /* run */
> 2, /* Num Elements */
> APPLY_WINDOW, /* Flag */
> {
> /* N p f a */
> /* 0 */ { 2, 0, 480, -240 },
> /* 1 */ { 0, 0, 0, 500 },
> /* 2 */ { 0, 0, 0, 0 },
> /* 3 */ { 0, 0, 0, 0 },
> /* 4 */ { 0, 0, 0, 0 },
> /* 5 */ { 0, 0, 0, 0 },
> /* 6 */ { 0, 0, 0, 0 },
> /* 7 */ { 0, 0, 0, 0 },
> /* 8 */ { 0, 0, 0, 0 },
This is seriously wrong. You just specified 9 initializers for an
8-element array.
> Ok, let's just say element is bigger than my example above and there are
> about a 1000 of these, only half of which have data. I've inherited
> this code and this table is occupying 300k of memory and memory's tight.
With all due respect, if 300k ever compiled in the first place, you
don't have the beginnings of an idea what "memory is tight" actually
means. People use C in environments where 300 bytes of RAM would be
unheard-of luxury.
> I want to delete all the filler rows and declare element in a way that
> the compiler will auto size what it needs for each instance.
That can be done, but on the scale you mention it will only be
manageable by an automated source code generation tool. You'll have to
store each array in a separate throw-away variable, then replace the
array by a pointer-to-element, initialized to the address of the leading
element of each of those throw-away variables. So each array eventually
appears in several places in the source code, linked to each other by
nothing but the variable name. The general pattern would be
throw_away_array_1 = { element0, element1 };
throw_away_array_2 = { e0, e1, e2, e3, e4, e5};
/* ... */
t_Monster monster = {
{ sizeof(throw_away_array_1)/sizeof(throw_away_array_1[0]),
throw_away_array_1 },
{ sizeof(throw_away_array_2)/sizeof(throw_away_array_2[0]),
throw_away_array_2 },
{ sizeof(throw_away_array_3)/sizeof(throw_away_array_3[0]),
throw_away_array_3 },
};
--
comp.lang.c.moderated - moderation address: clcm@[EMAIL PROTECTED]
-- you must
have an appropriate newsgroups line in your header for your mail to be
seen,
or the newsgroup name in square brackets in the subject line. Sorry.
|
