include file

 include file

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

 RE: include file

can you tell me how to include c file in another c file

i is be answereding the qeusetion.

#include "file.c"

 RE: include file

Get a textbook on C. This is not a Keil problem but a beginners errors using C.

 RE: i is be answereding the qeusetion.

Yes, you answered the question - unfortunately, it was the wrong question.

While it is true that you can include one 'C' file within another like that, it is almost certainly not a good way to proceed.

As already noted, get a 'C' textbook; this is standard 'C' programming practice - nothing specifically to do with Keil.

 RE: include file

In this case look for the the difference between a definition and a declaration. And the Keyword "extern"

 RE: include file

hello everyone,
thanx to all for reply
my problem is solved and as you said, including .c file is not good programming practice
i have not included .c file
but i separated repective variable of respective .c files
and declared these variables as extern in main .c file
i was including header files again and again and due to that i got error

thanx a lot for suggestions
take care

 RE: include file

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

 RE: include file

#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 ..."

 RE: include file

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.

 RE: include file

"Yes - I was actually waiting for that remark :)"

I see, you were testing us then.

 RE: include file

I saw the code-name "CHARLIE" and immediately fell for it (it had to be a redhead!). Got me, Per!

 RE: include file

Thanks Dan, I didn't know this about "_[A-Z_]..." identifiers.

 RE: include file

Or from the "Embedded Muse 169" (http://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 :-)

 RE: include file

hello,

I do like it,
include <main.c> and <global.c> in your project, but not the <global.h> and <constant definition.h>

<main.c> : // main program
#include <global.h>
#include <constant definition.h>

<global.c> : //variable declaration and initialisation
#include <constant definition.h>
unsigned char variable1 = 5;
unsigned char variable2 = constante2; (= 5)

<global.h> : //must be include in all c file of your project but not in <global.c>
extern unsigned char variable1;
extern unsigned char variable2;

<constant definition.h> :
constante2 5

 RE: include file

This is not valid code:

constante2 5

Some alternatives:

const int constante2 = 5;

enum {
    constante2 = 5
}

#define constante2 5

But I'm not so fond of constants that doesn't stand out as constants.

I prefer to use all caps, just as the normal convention for #define constants.

Note that 'const int' may affect the code generation for your 8-bit processor.

 RE: include file

<global.h> : //must be include in all c file of your project but not in <global.c>

Actually it is advantageous if you do include global.h in global.c - that way the compiler can warn you of any inconsistencies!

:-)

But I don't think that simply dumping all your globals into a single file is a good idea...

 RE: include file

Sorry to take you to task Mr. Westermark, but I simply must disagree on the issue of "Best Practices" with respect to that type of #ifndef #define #endif usage.

I do not rely on such a methods that intrinsically asks:

#ifndef DRINK_C_COOLAID   // "Gee, did I already declare that?"
#define DRINK_C_COOLAID 9 // "I didn't?" ... "I guess I better do it now."
#endif                    // "I really hope no other file has that #define too"

The very use of this construct implies that the source code is not tightly engineered. (I consider that a bad thing).

Don't get me wrong there Per, *they* all do it that way. It is all too common in the Main Stream C world.

I don't do that construct. I like total control [and domination] over my source code (most likely due to my 'ego trouble' ;-).

Cheers,

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 RE: include file

I agree that you should not need to protect a #define with a conditional.

But you may have to protect a complete header file.

Let's say that it contains definitions for uint8, uint16 etc. All source files should have it. But none twice.

 RE: include file

Just a follow-up about guard code for defines and guard code around individual symbols.

Guard code around an individual symbol may seem good, but have a big implication:

lib_header_1.h

#if !defined(MY_CONSTANT)
#define MY_CONSTANT 10
#endif

lib_header_2.h

#if !defined(MY_CONSTANT)
#define MY_CONSTANT 20
#endif

source_file_alt1.c

#include "lib_header_1.h"
#include "lib_header_2.h"
int my_data[MY_CONSTANT];

source_file_alt2.c

#include "lib_header_2.h"
#include "lib_header_1.h"
int my_data[MY_CONSTANT];

The end result will be an application that behaves differently depending on the include order of the two header files, and the developer will have no good way of figuring out why.

It is better if a library function either has a really hard limit, or is written to take the limit at run time.

But for a nother case - guarding full header files.

comlib_type_defines.h

typedef unsigned char comlib_uchar;

comlib_protocol1.h

void library1_function(comlib_uchar a);

library_protocol2.h

void library2_function(comlib_uchar a);

Now it would be nice if an end user may use either library_protocol1, or library_protocol2 or both, without having to know that the two protocol libraries have a common part with a common header file, i.e. all four examples should be allowed:

example_only_1.c

#include "comlib_protocol1.h"

...

example_only_2.c

#include "comlib_protocol2.h"

...

exampley_both_a.c

#include "comlib_protocol1.h"
#include "comlib_protocol2.h"

...

example_both_b.c

#include "comlib_protocol2.h"
#include "comlib_protocol1.h"

...

But it is important to note that comlib_protocol1.h, comlib_protocol2.h and the common file comlib_type_defines.h may not play with conditionally defined symbols. As soon as the end user is allowed to replace the value of an individual symbol, the developer got a vey big loaded gun preaimed at his/her own foot.www