Style question: #include

[Francine.Neary]

I have a program that uses a large lookup table, provided as a large
array in the source:

static int bigtbl[]={123, 456,
/* etc. etc. */
9999 };

Now this table is pretty big, and having it clutter up my main source
file is quite ugly. So I'd like to put it in a separate file and
#include that.

The style question is: should the separate file have a .c or .h
extension? There are two conventions, and I need to violate one of
them!
1) #including a .c file is weird.
2) putting a definition, rather than just declarations, in a .h file
is also weird.

Thoughts?

 

[Xu Weijiang]

Maybe you can put it in a special named file such as *bigtbl.data*.

I have a program that uses a large lookup table, provided as a large
array in the source:

static int bigtbl[]={123, 456,
/* etc. etc. */
9999 };

Now this table is pretty big, and having it clutter up my main source
file is quite ugly. So I'd like to put it in a separate file and
#include that.

The style question is: should the separate file have a .c or .h
extension? There are two conventions, and I need to violate one of
them!
1) #including a .c file is weird.
2) putting a definition, rather than just declarations, in a .h file
is also weird.

Thoughts?

Best regards
Xu Weijiang

 

[Mike Wahler]

I have a program that uses a large lookup table, provided as a large
array in the source:

static int bigtbl[]={123, 456,
/* etc. etc. */
9999 };

Now this table is pretty big, and having it clutter up my main source
file is quite ugly. So I'd like to put it in a separate file and
#include that.

The style question is: should the separate file have a .c or .h
extension? There are two conventions, and I need to violate one of
them!
1) #including a .c file is weird.

Some might call it weird, others not. But it's perfectly
valid. I'd use either .c or some other extension which
indicates what it is, perhaps .tbl

2) putting a definition, rather than just declarations, in a .h file
is also weird.

Same remarks about 'weird' as above. In a file (whatever its
name) intended to be #included by more than one other file
(the traditional meaning of a 'header file), it would not be
a good idea.

I've also seen the following form in third party libraries I've used:


/* ext.h */
#define EXTERN extern


/* array.h */
EXTERN int array[SIZE];


/* array.c */
#define EXTERN
#include "array.h" /* 'EXTERN' resolves to nothing, so definition occurs */


/* otherfiles.c */
#include ext.h
#include array.h /* causes extern declaration */


I don't really care for that way, I'd probably use
something like a .tbl file



-Mike

 

[CBFalconer]

I have a program that uses a large lookup table, provided as a large
array in the source:

static int bigtbl[]={123, 456,
/* etc. etc. */
9999 };

Now this table is pretty big, and having it clutter up my main source
file is quite ugly. So I'd like to put it in a separate file and
#include that.

The style question is: should the separate file have a .c or .h
extension? There are two conventions, and I need to violate one of
them!
1) #including a .c file is weird.
2) putting a definition, rather than just declarations, in a .h file
is also weird.

Thoughts?

No, including a .c file is NOT weird. Being a .c file, you are
warned not to #include it in multiple sources (as you normally can
a .h file). You could also make it a .d or .dat etc. file if you
wish.

 

[ranjeet.gupta]

I have a program that uses a large lookup table, provided as a large
array in the source:

static int bigtbl[]={123, 456,
/* etc. etc. */
9999 };

Now this table is pretty big, and having it clutter up my main source
file is quite ugly. So I'd like to put it in a separate file and
#include that.

The style question is: should the separate file have a .c or .h
extension? There are two conventions, and I need to violate one of
them!
1) #including a .c file is weird.
2) putting a definition, rather than just declarations, in a .h file
is also weird.

Thoughts?

Can you share the logic/Algo which you are runnig on your lookup
table,
Just wanted to know as I also have such a big lookup table, and
my major concern about it is that I need to reduce the search time.
(Optimising)

Can others also help and provide there thoughts.

Thanks
Ranjeet Gupta

 

[William Pursell]

I have a program that uses a large lookup table, provided as a large
array in the source:

static int bigtbl[]={123, 456,
/* etc. etc. */
9999 };

Now this table is pretty big, and having it clutter up my main source
file is quite ugly. So I'd like to put it in a separate file and
#include that.

The style question is: should the separate file have a .c or .h
extension? There are two conventions, and I need to violate one of
them!
1) #including a .c file is weird.

I agree strongly.

2) putting a definition, rather than just declarations, in a .h file
is also weird.

Also agreed. You can conform to both of these by using
the linker...

$ for i in data.h data.c foo.c; do echo "***** $i *****"; cat $i; done
***** data.h *****

#define TBL_SIZE 3
extern int bigtbl[ TBL_SIZE ];
***** data.c *****
#include "data.h"

int bigtbl[ TBL_SIZE ] = { 0, 1, 2};
***** foo.c *****

#include <stdio.h>
#include "data.h"

int
main(void)
{
printf( "Last entry:%d\n", bigtbl[ TBL_SIZE - 1 ]);
return 0;
}
$ gcc -c data.c
$ gcc -c foo.c
$ gcc -o foo foo.o data.o
$ ./foo
Last entry:2

 

[Dave Hansen]

I have a program that uses a large lookup table, provided as a large
array in the source:

static int bigtbl[]={123, 456,
/* etc. etc. */
9999 };

Now this table is pretty big, and having it clutter up my main source
file is quite ugly. So I'd like to put it in a separate file and
#include that.

The style question is: should the separate file have a .c or .h
extension? There are two conventions, and I need to violate one of
them!
1) #including a .c file is weird.
2) putting a definition, rather than just declarations, in a .h file
is also weird.

Thoughts?

When I've done this sort of thing in the past, the #included file was
generated automatically, and did not contain the declaration itself.
It also had the extension ".data". So I'd do something like this in
main.c:

#include <stdio.h> /* or whatever you need */

static int bigtbl[] = {
#include "bigtbl.data"
};

/* etc. */

HTH,

-=Dave

 

[tguclu]

I have a program that uses a large lookup table, provided as a large
array in the source:

static int bigtbl[]={123, 456,
/* etc. etc. */
9999 };

Now this table is pretty big, and having it clutter up my main source
file is quite ugly. So I'd like to put it in a separate file and
#include that.

The style question is: should the separate file have a .c or .h
extension? There are two conventions, and I need to violate one of
them!
1) #including a .c file is weird.
2) putting a definition, rather than just declarations, in a .h file
is also weird.

Thoughts?

When I've done this sort of thing in the past, the #included file was
generated automatically, and did not contain the declaration itself.
It also had the extension ".data". So I'd do something like this in
main.c:

#include <stdio.h> /* or whatever you need */

static int bigtbl[] = {
#include "bigtbl.data"
};

/* etc. */

HTH,

-=Dave- Hide quoted text -

- Show quoted text -

Hi
How was "bigtb.data" structured ?
Since you have already used curly brackets , is it only values
seperated with commas ?

 

[Roland Pibinger]

Some might call it weird, others not. But it's perfectly
valid. I'd use either .c or some other extension which
indicates what it is, perhaps .tbl

Microsoft uses .inl (probably means 'inline').

 

[Dave Hansen]

static int bigtbl[] = {
#include "bigtbl.data"
};

[...]

Hi
How was "bigtb.data" structured ?
Since you have already used curly brackets , is it only values
seperated with commas ?

Exactly. It made the application that generated bigtbl.data a little
easier to write as well.

Regards,

-=Dave

 

[Old Wolf]

I have a program that uses a large lookup table, provided as a
large array in the source:

static int bigtbl[]={123, 456,
/* etc. etc. */
9999 };

1) #including a .c file is weird.

Not really, that would be my preferred solution here.

Also, you could help the compiler out by declaring
the array as const (assuming it is in fact meant
to not change).

 

[pete]

I have a program that uses a large lookup table, provided as a
large array in the source:

static int bigtbl[]={123, 456,
/* etc. etc. */
9999 };

1) #including a .c file is weird.

Not really, that would be my preferred solution here.

Also, you could help the compiler out by declaring
the array as const (assuming it is in fact meant
to not change).

I would remove the static,
and declare the array as extern in a.h,
and include "a.h" in main.c
and have int bigtbl in a.c.

 

[Old Wolf]

I would remove the static,
and declare the array as extern in a.h,
and include "a.h" in main.c
and have int bigtbl in a.c.

I like encapsulation -- if a data table is
only meant to be used in one place, then I
like it to be only visible in that one place,
and not externally visible.

 

[August Karlstrom]

(e-mail address removed) skrev:

I have a program that uses a large lookup table, provided as a large
array in the source:

static int bigtbl[]={123, 456,
/* etc. etc. */
9999 };

Now this table is pretty big, and having it clutter up my main source
file is quite ugly. So I'd like to put it in a separate file and
#include that.

The style question is: should the separate file have a .c or .h
extension? There are two conventions, and I need to violate one of
them!
1) #including a .c file is weird.
2) putting a definition, rather than just declarations, in a .h file
is also weird.

Thoughts?

You could also read the data from a file.


August

 

[Manish Tomar]

You could take the table and put it in another c "table.c" file which
will be among the list of files that are compiled and linked. its
associated "table.h" will contain extern of the table which can be
included in other modules and used. What say?

 

[Francine.Neary]

You could take the table...

I have a program that uses a large lookup table, provided as a large
array in the source:

static int bigtbl[]={123, 456,
/* etc. etc. */
9999 };

Now this table is pretty big, and having it clutter up my main source
file is quite ugly. So I'd like to put it in a separate file and
#include that.

The style question is: should the separate file have a .c or .h
extension?

You could take the table and put it in another c "table.c" file which
will be among the list of files that are compiled and linked.

Say yes - this is what I did, and with hindsight it seems fine to me.

its
associated "table.h" will contain extern of the table which can be
included in other modules and used. What say?

Say no way - violates encapsulation. (Did you miss the static?)

 

[Al Balmer]

You could take the table...

I have a program that uses a large lookup table, provided as a large
array in the source:

static int bigtbl[]={123, 456,
/* etc. etc. */
9999 };

Now this table is pretty big, and having it clutter up my main source
file is quite ugly. So I'd like to put it in a separate file and
#include that.

The style question is: should the separate file have a .c or .h
extension?

You could take the table and put it in another c "table.c" file which
will be among the list of files that are compiled and linked.

Say yes - this is what I did, and with hindsight it seems fine to me.

its
associated "table.h" will contain extern of the table which can be
included in other modules and used. What say?

Say no way - violates encapsulation. (Did you miss the static?)

If you're after encapsulation, then the access functions for the table
go in the same .c file, and the .h file contains their prototypes.

Including the table in files that use it doesn't provide any
encapsulation.

 

[Dave Hansen]

Including the table in files that use it doesn't provide any
encapsulation.

However, defining the table static in the one and only file that uses
it does provide data hiding. Which is often conflated with
encapsulation.

Regards,

-=Dave