please wait
File scope.
Mar 30, 2012 at 2:01pm
Hello,
After some very odd "unresolved extern symbol" errors, I'm wondering whether there's such a thing as "file scope".
Basically, I have one header file with a class definition, that holds the declaration for nearly all functions in the project. To split up the code load, I've subgrouped the functions by "module". Now, it turns out a function in one .cpp file can't call a function in a different .cpp file (even if they both belong to the same class and are thus declared in the same header file).
Is there a way around this?
After some very odd "unresolved extern symbol" errors, I'm wondering whether there's such a thing as "file scope".
Basically, I have one header file with a class definition, that holds the declaration for nearly all functions in the project. To split up the code load, I've subgrouped the functions by "module". Now, it turns out a function in one .cpp file can't call a function in a different .cpp file (even if they both belong to the same class and are thus declared in the same header file).
Is there a way around this?
Mar 30, 2012 at 2:54pm
You need to link the objects.
¿What environment are you using?
¿What environment are you using?
$ g++ -c *.cpp #compile
$ g++ *.o -l{some,other,libraries} -o program.bin #linking |
Apr 2, 2012 at 8:19am
Make sure you're adding all the source files to your project/solution.
Apr 2, 2012 at 8:43am
They're all in the project. The problem only occurs when function A uses function B, but function B's definition is in a different file.
It feels like one file (with function A) is being compiled before the other (with function B), thus the compiler doesn't know what to fill in for the call to B. My instincts tell me that's not how compilers work though.
[edit]
It's not a game-breaking problem; I'll just spend a bit more time deciding which code goes where. Would still be handy to know if this can be avoided.
It feels like one file (with function A) is being compiled before the other (with function B), thus the compiler doesn't know what to fill in for the call to B. My instincts tell me that's not how compilers work though.
[edit]
It's not a game-breaking problem; I'll just spend a bit more time deciding which code goes where. Would still be handy to know if this can be avoided.
Last edited on Apr 2, 2012 at 8:44am
Apr 2, 2012 at 2:21pm| My instincts tell me that's not how compilers work though. |
Don't know about your IDE. But check what it is doing (how is compiling, what files, etc)
Maybe you would have more control generating a makefile.
Apr 2, 2012 at 2:33pm
My guess is that the function in question is an inline function with external linkage - this would need to be defined (with the same definition) in every translation unit in which it is used.
If there are inline functions, move their definitions to the header file.
If there are inline functions, move their definitions to the header file.
Apr 3, 2012 at 9:27am
Ah yes, it was declared "inline", but the actual body of the function was somewhere else. Makes perfect sense now that I think about it. Thanks, JLBorges!
@ne555: I've never used makefiles (or the command line, or anything beyond the IDE). I'm not sure they'd be very useful for my line of work, but if you know of any easy (and preferably short) introduction on makefiles, I'd love a link!
@ne555: I've never used makefiles (or the command line, or anything beyond the IDE). I'm not sure they'd be very useful for my line of work, but if you know of any easy (and preferably short) introduction on makefiles, I'd love a link!
Topic archived. No new replies allowed.