Defined More Than Once - Help?

Started by
3 comments, last by RapidStunna 21 years, 6 months ago
Because of the currently disabled forum searching, this may have been asked before. And doing a search on public search engines didn't turn up much because I wasn't sure what to search for. Anyways, my situation's this. I have a math header which includes definitions of the math functions and structures. The source for the functions is split up among many cpp files that match the function's purpose. For example, all my vector functions go in vector.cpp. Same with matrix.cpp and trig.cpp. One thing I would like to have in the math.h header file is a sin and cosine lookup table. I've already precomputed the values and have them stored in something to this extent (except longer - just the format): const extern float sin_lut[] = {n1, n2, n3 ... nn} And the same goes for the cosine one. When its included however into the cpp files the table is defined more than once when it gets included seperatly into each one in each .cpp file which causes the compiler to spit out a few uncompilable errors. This will probobly happen also if I include it in other files. A function to look it up isn't an option because functions are slightly slower for my purposes than a look up table. Is there a way which I can define the table so that is doesn't get defined for each time it's included? Oh yea, and yes I have header guards but they don't do anything for this. Is it possible to have a similar idea for the tables though? ---
Brent Gunning | My Site Edit: Abbreviations from chats don't work here, forgot. [edited by - RapidStunna on October 15, 2002 8:13:16 PM]
Advertisement
''extern'' means it''s a declaration, not a definition. It means, "there''s an object called sin_lut, this is its type, but it''s not here". The object is "found" at the link step.

When you put an "= { ... };" after it, it changes the statement into a definition. In effect, the extern gets ignored--it''s trumped by the assignment. Therefore, if you include this file in more than one project, you''ll have multiply-defined symbols.

What should you do instead? The canonical form is to declare it extern _without_ assignment (declare it), and then make your assignment in a _single_ .c file (define it).

The problem with this is that you have to dereference a pointer to get to the array, whereas if you had the values in the .h file somehow, and you needed to dereference by a constant value, you could optimize this out. One way to accomplish this is to make the array static in the .h file--this would make every .c file that included the .h file have a copy of the array in its code file. This could adversely affect your code size.

For your case, since you''d hardly ever need a constant offset into a sine array, the canonical method is probably the best for you.
Thank you so much Stoffel. Although I use C++ all the time, stuff like what you know never really stuck because there was no reason to use it until now. Anyways, there''s another quick problem. The problem is when using the Intel JPEG library VC++ gives me this warning:

LINK : warning LNK4098: defaultlib "LIBC" conflicts with use of other libs; use /NODEFAULTLIB:library

I did a search in the vc++ docs but couldn''t find anything too useful. Other source (particularly gametutorials.com''s opengl jpeg using tutorial) also gives this warning. It doesn''t affect the compilation but it''s just not pretty not having a perfect compile. Does anyone know what it is and how to get rid of it?
The IJL library was built with a certain set of compiler options (no debug, single threaded) which caused resolving references to the LIBC.lib functions to be placed into the IJL libraries object code.

You''re project build in which you get the warning is using a different set of options, e.g., debug and/or multi-threaded, so the linker is letting you know via this warning that you''re trying to "mix" libraries.
Thanks again. It makes sense. After changing the active build to release, the errors have stopped.

---
Brent Gunning | My Site

This topic is closed to new replies.

Advertisement