By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,503 Members | 1,615 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,503 IT Pros & Developers. It's quick & easy.

Big tables in .h file!

P: n/a
Hello, gurus.

http://cvs.gnome.org/viewcvs/libunicode/msft/cp932.h?rev=1.2&view=markup"

I've stumbled upon an interesting thing. If you follow this link, you
will see huge translation tables (from ascii to unicode) located in H
file. Now. It is well known (at least to me), that such tables are
better to be stored in C file, right? So that in case of double
inclusion, bad things won't happen...

I really trust those gnome guys, I'm sure they're really smart, and
there was some thought behind this.

Please, give me a hint!!

Thanks

Nov 15 '05 #1
Share this Question
Share on Google+
18 Replies


P: n/a
Zhekka a écrit :
http://cvs.gnome.org/viewcvs/libunicode/msft/cp932.h?rev=1.2&view=markup"

I've stumbled upon an interesting thing. If you follow this link, you
will see huge translation tables (from ascii to unicode) located in H
file.


Absolute nonsense. The guy who has written the code generator desserves
honey and fire ants...

--
A+

Emmanuel Delahaye
Nov 15 '05 #2

P: n/a
Emmanuel Delahaye <em***@YOURBRAnoos.fr> writes:
Zhekka a icrit :
http://cvs.gnome.org/viewcvs/libunicode/msft/cp932.h?rev=1.2&view=markup"
I've stumbled upon an interesting thing. If you follow this link, you
will see huge translation tables (from ascii to unicode) located in H
file.


Absolute nonsense. The guy who has written the code generator desserves
honey and fire ants...


I imagine that this .h file is included in only one .c file.
That is, it's not really a header, it's just a generated table
for including in some source file. I usually use a .inc
extension for such code to avoid confusing people.
--
"In My Egotistical Opinion, most people's C programs should be indented six
feet downward and covered with dirt." -- Blair P. Houghton
Nov 15 '05 #3

P: n/a
Zhekka wrote:
Hello, gurus.

http://cvs.gnome.org/viewcvs/libunicode/msft/cp932.h?rev=1.2&view=markup"

I've stumbled upon an interesting thing. If you follow this link, you
will see huge translation tables (from ascii to unicode) located in H
file. Now. It is well known (at least to me), that such tables are
better to be stored in C file, right? So that in case of double
inclusion, bad things won't happen...

I really trust those gnome guys, I'm sure they're really smart, and
there was some thought behind this.

Please, give me a hint!!


see the "inclusion guards"?

#ifndef MSFT_CP932_H
#define MSFT_CP932_H
....
#endif /* MSFT_CP932_H */

these prevent double inclusion :)

bye.
Nov 15 '05 #4

P: n/a
cane wrote:
Zhekka wrote:
Hello, gurus.

http://cvs.gnome.org/viewcvs/libunicode/msft/cp932.h?rev=1.2&view=markup"

I've stumbled upon an interesting thing. If you follow this link, you
will see huge translation tables (from ascii to unicode) located in H
file. Now. It is well known (at least to me), that such tables are
better to be stored in C file, right? So that in case of double
inclusion, bad things won't happen...

I really trust those gnome guys, I'm sure they're really smart, and
there was some thought behind this.
Please, give me a hint!!

see the "inclusion guards"?

#ifndef MSFT_CP932_H
#define MSFT_CP932_H
...
#endif /* MSFT_CP932_H */

these prevent double inclusion :)


Actually, it doesn't seem to prevent it. I once came to this conclusion
doing similar thing; including static tables header from multiple C
files - Then I decided to include file only from one C file (as Ben
Pfaff already suggested).

If somebody could enlighten me - why include guard doesn't work in this
case?

test:
====

main.c:
#include <stdlib.h>
#include "cp932.h"
int main(int argc, char* argv[]) { return 0; }

dummy.c
#include <stdlib.h>
#include "cp932.h"
void dummy(void) {}
gcc -o test.exe main.c dummy.c
gives about 66 KB exe

gcc -o test.exe main.c
(or commenting out cp932.h include in dummy.c)
gives about 41 KB exe

with respect,
Toni Uusitalo



Nov 15 '05 #5

P: n/a
In article <43***********************@reader1.news.tin.it>,
cane <x@x.com> wrote:
see the "inclusion guards"?

#ifndef MSFT_CP932_H
#define MSFT_CP932_H
...
#endif /* MSFT_CP932_H */

these prevent double inclusion :)


They prevent double inclusion *in one .c file*, but if they are
included by multiple .c files that are linked together, it won't
help. Presumably you're not meant to do that.

-- Richard
Nov 15 '05 #6

P: n/a
ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <43***********************@reader1.news.tin.it>,
cane <x@x.com> wrote:
see the "inclusion guards"?

#ifndef MSFT_CP932_H
#define MSFT_CP932_H
...
#endif /* MSFT_CP932_H */

these prevent double inclusion :)


They prevent double inclusion *in one .c file*, but if they are
included by multiple .c files that are linked together, it won't
help. Presumably you're not meant to do that.


Also of course because the declaration is static, each module that
#includes the file will likely get its own private copy of the table,
possibly unknown to the programmer.

--

John Devereux
Nov 15 '05 #7

P: n/a

"John Devereux" <jd******@THISdevereux.me.uk> wrote in message
news:87************@cordelia.devereux.me.uk...
Also of course because the declaration is static, each module that
#includes the file will likely get its own private copy of the table,
possibly unknown to the programmer.


So what's the syntax to make a declaration 'global'? Then any link loader
will detect such multiple definitions.

Bart C.
Nov 15 '05 #8

P: n/a

Bart C wrote:
"John Devereux" <jd******@THISdevereux.me.uk> wrote in message
news:87************@cordelia.devereux.me.uk...
Also of course because the declaration is static, each module that
#includes the file will likely get its own private copy of the table,
possibly unknown to the programmer.


So what's the syntax to make a declaration 'global'? Then any link loader
will detect such multiple definitions.

Bart C.


The 'syntax' is to put it in a .c file and declare an extern to it in a
..h file.

Nov 15 '05 #9

P: n/a
In article <43**********@mk-nntp-2.news.uk.tiscali.com> "Bart C" <bc@freeuk.com> writes:

"John Devereux" <jd******@THISdevereux.me.uk> wrote in message
news:87************@cordelia.devereux.me.uk...
Also of course because the declaration is static, each module that
#includes the file will likely get its own private copy of the table,
possibly unknown to the programmer.


So what's the syntax to make a declaration 'global'? Then any link loader
will detect such multiple definitions.


Not making it static.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Nov 15 '05 #10

P: n/a
Dik T. Winter wrote:
In article <43**********@mk-nntp-2.news.uk.tiscali.com> "Bart C" <bc@freeuk.com> writes:
>
> "John Devereux" <jd******@THISdevereux.me.uk> wrote in message
> news:87************@cordelia.devereux.me.uk...
>
> > Also of course because the declaration is static, each module that
> > #includes the file will likely get its own private copy of the table,
> > possibly unknown to the programmer.

>
> So what's the syntax to make a declaration 'global'? Then any link loader
> will detect such multiple definitions.


Not making it static.


There is no guarantee that the linker will complain if this leads to
multiple definitions, since multiple definitions lead to undefined
behaviour. Indeed, I've had it not complain at link time but had strange
effects at run time when someone else got this wrong.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Nov 15 '05 #11

P: n/a
Ben Pfaff wrote:
Emmanuel Delahaye <em***@YOURBRAnoos.fr> writes:

Zhekka a icrit :
http://cvs.gnome.org/viewcvs/libunicode/msft/cp932.h?rev=1.2&view=markup"
I've stumbled upon an interesting thing. If you follow this link, you
will see huge translation tables (from ascii to unicode) located in H
file.


Absolute nonsense. The guy who has written the code generator desserves
honey and fire ants...

I imagine that this .h file is included in only one .c file.
That is, it's not really a header, it's just a generated table
for including in some source file. I usually use a .inc
extension for such code to avoid confusing people.


What are other people's approaches to this kind of thing? My
approach would be to have a .c containing the translation table
and a .h with the extern declaration. It prevents you using
internal scope though. But my formal C training is somewhat
lacking...

--
imalone
Nov 15 '05 #12

P: n/a
Ian Malone wrote:

Ben Pfaff wrote:
Emmanuel Delahaye <em***@YOURBRAnoos.fr> writes:

Zhekka a icrit :

http://cvs.gnome.org/viewcvs/libunicode/msft/cp932.h?rev=1.2&view=markup"
I've stumbled upon an interesting thing. If you follow this link, you
will see huge translation tables (from ascii to unicode) located in H
file.

Absolute nonsense. The guy who has written the code generator desserves
honey and fire ants...

I imagine that this .h file is included in only one .c file.
That is, it's not really a header, it's just a generated table
for including in some source file. I usually use a .inc
extension for such code to avoid confusing people.


What are other people's approaches to this kind of thing? My
approach would be to have a .c containing the translation table
and a .h with the extern declaration. It prevents you using
internal scope though. But my formal C training is somewhat
lacking...


I have tables like that, in which the data is in an included ".inc" file,
and the code is in the usual ".c" file. This is especially true when the
data tables are needed by more than one executable, but the code which
uses the table may be different.

Or, perhaps there are several tables, each for the same purpose, but with
different data. For example, collating order and upper/lowercase
conversions for different lauguages/codepages. We have an "english.inc",
a "spanish.inc", a "portuguese.inc", and so on. A single module then
includes the appropriate language tables. Additional languages can be
added by creating new include files, and including them from the main
module. (We also can load from external data files. But that's another
story.)

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

Nov 15 '05 #13

P: n/a
On Thu, 10 Nov 2005 11:57:34 +0000, Ian Malone <ib***@cam.ac.uk>
wrote:
Ben Pfaff wrote:
Emmanuel Delahaye <em***@YOURBRAnoos.fr> writes:

Zhekka a icrit :

http://cvs.gnome.org/viewcvs/libunicode/msft/cp932.h?rev=1.2&view=markup"
I've stumbled upon an interesting thing. If you follow this link, you
will see huge translation tables (from ascii to unicode) located in H
file.

Absolute nonsense. The guy who has written the code generator desserves
honey and fire ants...

I imagine that this .h file is included in only one .c file.
That is, it's not really a header, it's just a generated table
for including in some source file. I usually use a .inc
extension for such code to avoid confusing people.


What are other people's approaches to this kind of thing? My
approach would be to have a .c containing the translation table
and a .h with the extern declaration. It prevents you using
internal scope though. But my formal C training is somewhat
lacking...


I'd have to study the problem, but quite likely, I'd have a .c file
containing both the tables and the functions which operate on them.
There would be a corresponding .h file presenting the user interface
(the function prototypes.) Usually, there's no need to make the tables
themselves visible to other modules.
--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 15 '05 #14

P: n/a
Ian Malone <ib***@cam.ac.uk> writes:
Ben Pfaff wrote:
Emmanuel Delahaye <em***@YOURBRAnoos.fr> writes:
Zhekka a icrit :

http://cvs.gnome.org/viewcvs/libunicode/msft/cp932.h?rev=1.2&view=markup"
I've stumbled upon an interesting thing. If you follow this link, you
will see huge translation tables (from ascii to unicode) located in H
file.

Absolute nonsense. The guy who has written the code generator
desserves honey and fire ants... I imagine that this .h file is included in only one .c file.
That is, it's not really a header, it's just a generated table
for including in some source file. I usually use a .inc
extension for such code to avoid confusing people.


What are other people's approaches to this kind of thing? My
approach would be to have a .c containing the translation table
and a .h with the extern declaration. It prevents you using
internal scope though.


That's the usual approach. I would use a .inc in the case where
the data table is generated by a program (as it appears to be in
the above link) and I want to include some additional code in the
same translation unit (and the generator program is not amenable
to that).
But my formal C training is somewhat lacking...


Is there such a thing as "formal C training"? I don't have any
either.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
Nov 15 '05 #15

P: n/a
Ben Pfaff a écrit :
Emmanuel Delahaye <em***@YOURBRAnoos.fr> writes:

Zhekka a icrit :
http://cvs.gnome.org/viewcvs/libunicode/msft/cp932.h?rev=1.2&view=markup"
I've stumbled upon an interesting thing. If you follow this link, you
will see huge translation tables (from ascii to unicode) located in H
file.


Absolute nonsense. The guy who has written the code generator desserves
honey and fire ants...


I imagine that this .h file is included in only one .c file.
That is, it's not really a header, it's just a generated table
for including in some source file. I usually use a .inc
extension for such code to avoid confusing people.


Agreed.

--
A+

Emmanuel Delahaye
Nov 15 '05 #16

P: n/a
cane a écrit :
see the "inclusion guards"?

#ifndef MSFT_CP932_H
#define MSFT_CP932_H
...
#endif /* MSFT_CP932_H */

these prevent double inclusion :)


So what ? Do you reall know the purpose of this guards ? It protects
against multiple inclusion *in the same translation unit*. No effect if
include the same .h in two or more different TU. Got it ?

--
A+

Emmanuel Delahaye
Nov 15 '05 #17

P: n/a
John Devereux a écrit :
Also of course because the declaration is static, each module that
#includes the file will likely get its own private copy of the table,
possibly unknown to the programmer.


With a useless double or more use of the memory space, which desserves
double or more rations of honey and fire ants...

--
A+

Emmanuel Delahaye
Nov 15 '05 #18

P: n/a
Bart C a écrit :
"John Devereux" <jd******@THISdevereux.me.uk> wrote in message
news:87************@cordelia.devereux.me.uk...

Also of course because the declaration is static, each module that
#includes the file will likely get its own private copy of the table,
possibly unknown to the programmer.

So what's the syntax to make a declaration 'global'? Then any link loader
will detect such multiple definitions.


/* .h */
#define SIZE ...
extern T a[SIZE];

/* .c */
T a[SIZE] = {...};

--
A+

Emmanuel Delahaye
Nov 15 '05 #19

This discussion thread is closed

Replies have been disabled for this discussion.