We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
hello everyone, i am writing a program for c8051f020,in which i have 4 ".c" files: main c file,keyroutine file, general routines files,confguration file
i separated bit addressable, data addressable, functions, #defines in separate header files
i included these header files in respective ".c" file
but i am getting following error in linking
1. public refers to ignored segment 2.address space overflow both for data as well as bit memory 3.multiple public definitions
i have put all ".c" files for build shall i continue or main c file should be put for building
if i do so then for debugging i will not be able to put breakpoint in other c files
can you tell me how to include c file in another c file
for further details pls let me know
thank you all take care
Best practices for header files says that you should always guard them from multiple inclusion:
charlie.h:
#ifndef _CHARLIE_H #define _CHARLIE_H ... #endif // _CHARLIE_H
Beware! From the standard:
"All identifiers that begin with an underscore and either an uppercase letter or another underscore are reserved ..."
Yes - I was actually waiting for that remark :)
I normally have a long prefix with company name etc at the start of the symbol, to make sure that it will be unique both compared to the standard and in relation to potential 3part libraries.
Many IDE has a feature to automatically add this inclusion guard, including some form of random number in the symbol name to make sure that no collision can happen.
"Yes - I was actually waiting for that remark :)"
I see, you were testing us then.
I saw the code-name "CHARLIE" and immediately fell for it (it had to be a redhead!). Got me, Per!
Thanks Dan, I didn't know this about "_[A-Z_]..." identifiers.
Or from the "Embedded Muse 169" (www.ganssle.com/tem-back.htm):
Steve Strobel wrote about header guards: I have adopted an unconventional include guard to detect and warn about such header include loops. It is even bigger and uglier than the standard include guard (which I think is ugly), but has saved me lots of frustration by letting me know when a cycle exists before I waste time trying to track down a bunch of related compiler errors. //------------------------------------------------------------ #ifdef main_h_include_finished #elif defined(main_h_include_started) #warning "HEADER FILE INCLUDE LOOP!!!" #else #define main_h_include_started //------------------------------------------------------------ // header file contents go here //------------------------------------------------------------ #define main_h_include_finished #endif //------------------------------------------------------------
Not sure though why he added "main_h_include_started", seems unnecessary, but adding a #warning is nice. As long as you don't have legacy spaghetti code that includes everything everywhere and a build system/compiler that stops on warnings :-)