From: goodTweetieBird on
I have three files, a.c b.c, and a.h. The original file a.c was
getting extremely large because it had several large arrays of structs
that were initialized in aggregate. I tried moving them to b.c but
that caused problems because I had consts or #defines afterwards that
give the size in bytes and length in elements as determined by sizeof
operations. One cannot use the const value later for an array size and
#define constants aren't seen by other .c files.

I can solve my problem by putting the arrays in the header file but
that doesn't seem proper. But since only a.c uses a.h would it be
acceptable?


Thanks,

gtb

Note: Developing in C not C++.
From: Victor Bazarov on
goodTweetieBird wrote:
> I have three files, a.c b.c, and a.h. The original file a.c was
> getting extremely large because it had several large arrays of structs
> that were initialized in aggregate. I tried moving them to b.c but
> that caused problems because I had consts or #defines afterwards that
> give the size in bytes and length in elements as determined by sizeof
> operations. One cannot use the const value later for an array size and
> #define constants aren't seen by other .c files.
>
> I can solve my problem by putting the arrays in the header file but
> that doesn't seem proper. But since only a.c uses a.h would it be
> acceptable?

Don't put them in a.h if there is a chance of some other file wanting to
include a.h for the definitions/declarations there. Put your data in a
separate .c file (like a2.c) and include that find in a.c:

#include "a2.c"

where appropriate.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
From: goodTweetieBird on
Thanks, Victor.



It's all in the name, eh? I have done that before but seemed to have
problems including a .c file.

However, I just tried your solution and it worked great.
gtb