C program in the header file contains the essence of each other (reproduced)

C program in the header file each other contains the essence (NET Summary) collection (transfer from: http://blog.csdn.net/lingyun3429/archive/2010/04/27/5535191.aspx)
The Declaration of variables, arrays, and functions defined in the. c file with the same name is generally placed in. h. Declarations that need to be used externally by. C.

1) H file function

1 Easy to develop: contains common constants, structures, type definitions, functions, variable declarations required by some files;

2 provides interface: For a package can provide an interface to the outside world (for example: stdio.h).

2) What should I have in the H file?

constants, structures, type definitions, functions, variable declarations.

3) H file should not have anything

Variable definition, function definition.

4) extern problem

extern is required for variables;

For a function it is not necessary because the default state of the function is extern. If a function is to be changed to be visible only within the file, add static.

5) include contains questions

Although the Declaration and type definitions can be duplicated, it is recommended that conditional compilation be used.

#ifndef _filename_h,

#define _filename_h

......

#endif

6) The H file should be included there

where needed. For example, an H file that provides an interface is only required for 1.c files, then it is included in the 1.c file.

The programs you write are generally available. h file and the corresponding. c file, the. h file is used by the declaration, and the. c file is part of its function implementation. As long as the call is contained. h file, we have not heard of the # include "DELAY.C" program, and do not advocate the use of this form.

In the Delay.h file://function declaration for the call

#ifndef __delay_h__

#define __delay_h__

extern void delayms (unsigned int n);

#endif

In the Delay.c file://Function Implementation section

#include <delay.h>

For Crystal 11.0592M

void delayms (unsigned int n)

{

unsigned int i,j;

for (j=n;j>0;j--)

for (i=112;i>0;i--);

}

In the main program MAIN.C

#include <delay.h>//The main program contains. h files and cannot contain. c files

Usually a C program project can be divided into several modules by function, a module usually consists of two documents to form a header file *.h, the data structure and function prototype in the module is described; the other is the C file *. C, define the data instance or object, and the specific implementation of the function algorithm, such as I2C.C, SPI. C, DAC. C, DISPLAY. C and so on, for the invocation of the file, we want to define a header file for each module, in terms of i2c.c, define I2C.H.

#ifndef Graphics_h

#define Graphics_h

#include <math.h >

...

#include "Myheader.h"

...

void Function1 (...);

...

Class Box

{

...

};

#endif

*************************************************************************************************************** ***************************************************************************************************

The modular program is a black box that only provides interfaces (global variables, external functions) to the outside, without requiring the caller to understand the process. Defining the interface as little as possible helps keep the module independent (the intrinsic and static global variables that do not need to be known by the user do not need to be given in the H file to avoid user confusion) write an include statement in the file that requires the module to be called. A good project, h file organization is very clear, only look at H file will be able to write the main program calls the corresponding C module.

The format of the header file is as follows (I²c. H for example):

********************************************************************

#ifndef I2c_h

#define I2c_h

..........

Bit SETSDA (bit up_down);

Bit SETSCL (bit up_down);

#endif

**********************************************************************

I2c. The C format is as follows:

**********************************************************************

#include < stdio.h >

#include "I2C.h"

void Sendbyte (Uchar c);

Bit SETSDA (bit up_down) {...};;

Bit SETSCL (bit up_down) {...};;

**********************************************************************

Another way to do this:

=============================

#ifndef I2c_h

#define I2c_h

..........

Exten bit SETSDA (bit up_down);

Exten bit SETSCL (bit up_down);

#endif

=================================================

I2c. The C format is as follows:

=================================================

#include < stdio.h >

void Sendbyte (Uchar c);

Bit SETSDA (bit up_down) {...};;

Bit SETSCL (bit up_down) {...};;

=================================================

For example, by the way, analyze ifndef/define/endif:

Suppose you have 4 files in your project, namely A.cpp, B.h, C.h, D.h.

The head of the A.cpp is:

#include "B.h"

#include "c.h"

The heads of B.h and c.h are:

#include "D.h"

And D.h has the definition of Class D.

In this way, the compiler compiled a.cpp, the first according to # # # "B.h" to compile b.h this problem, and then according to B.h inside the # include "D.h", to compile d.h this file, so that the d.h inside the class D compiled;

Then, according to the second sentence of A.cpp, "c.h", to compile c.h, eventually will find the d.h inside the Class D, but the Class D has been compiled before, so will report a redefinition error.

This redefinition error can be prevented by adding ifndef/define/endif. In the pre-compilation process, the implementation to include "C.h" when the previous sentence is defined as the Class D macro, so at this time the ifndef condition is not satisfied, the effect of preventing duplicate reference header file.

#undef只是撤消掉掉原来定义的宏, but will not cancel the variable you have already defined with this macro

#define X extern

x int A;

#undef X

You can still use this a, but you can't use X, and of course you define x as you like.

You can also define it as

#define X extern

x int A;

#undef X

#define X INT

X b;

#undef X

*************************************************************************************************************** ***************************************************************************************************

The partition of the module "zoned" is the meaning of the plan, meaning how to reasonably divide a large piece of software into a series of functional independent part of the system to complete the need for cooperation. C language as a structured programming language, in the division of the module in the main basis of function (according to the function of the division in the object-oriented design to become a mistake, Newton's law encountered the theory of relativity), C language modular programming needs to understand the following concepts:

(1) The module is a combination of a. c file and a. h file, and the header file (. h) is a declaration of the interface of the module;

(2) The external functions and data provided by a module to other modules are required to be declared with the extern keyword in the. h file;

(3) Functions and global variables within the module are declared with the static keyword at the beginning of the. c file;

(4) Never define a variable in the. h file! The difference between defining a variable and declaring a variable is that defining an operation that produces memory allocations is the concept of the assembly phase, whereas a declaration simply tells the module that contains the declaration to look for external functions and variables from other modules during the connection phase. Such as:

int a = 5;

#include "Module1.h"

#include "Module1.h"

#include "Module1.h"

The results of the above program are defined in Modules 1, 2, 3, the integer variable a,a in different modules corresponding to different address units, the world never need such a program. The correct approach is to:

extern int A;

#include "module1.h" int a = 5;

#include "Module1.h"

#include "Module1.h"

This way, if the module 1, 2, 3 operation A, corresponding to the same on-chip deposit cells.

*************************************************************************************************************** ***************************************************************************************************

The same is true of program design, if the concept is clear, it is basically no problem (it will be difficult in mathematics, such as the choice of algorithms, time space and efficiency, stability and balance of resources). But it's not that easy to master a clear concept. For example, see if you have a clear and thorough understanding of this.

A.h

void Foo ();

A.c

#include "a.h"//My question came out: this sentence is to, or not?

void Foo ()

{

Return

}

Main.c

#include "A.h"

int main (int argc, char *argv[])

{

Foo ();

return 0;

}

For the above code, please answer three questions:

A.C in the #include "a.h" This sentence is not redundant?
Why do you often see the xx.c include corresponding xx.h?
If A.C is not written, then does the compiler automatically bind the contents of the. h file with the. c file of the same name?
(Please carefully consider the above 3 questions for 10 minutes, MO should be anxious to see the explanations below.) :) The more you think about it, the deeper you will understand. ）

Okay, TIME's up! Please forget the 3 questions above and your thoughts on these three questions, and then listen to me slowly. The correct concept is: from the C compiler point of view,. h and. C are clouds, that is, the name of. txt,. doc is not a big difference. In other words, the. h and. C Have nothing to do with it. The declarations of variables, arrays, and functions defined in the. c file with the same name are generally placed in H. Declarations that need to be used externally by. C. What's the use of this statement? Just make it easy to quote where these statements are needed. Because #include "xx.h" this macro its actual meaning is to delete the current line, the contents of the xx.h is inserted in the current line position intact. Because there are so many places to write these function declarations (every call to a function in XX.C is declared all at once), a macro that uses #include "xx.h" simplifies many lines of code--and lets the preprocessor replace itself. In other words, xx.h actually just makes the call where the function declaration in the XX.C needs to be written (fewer lines can be written), as for the include. h file who, is it. h or. c, or the. h with the same name. C, there is no inevitable relationship.
So you might say, "Ah?" I usually just want to call a function in xx.c, but include the Xx.h file, is not a macro replacement after a lot of useless declarations? Yes, it does introduce a lot of rubbish, but it saves you a lot of ink, and the whole layout looks more refreshing. It is this truth that the fish and bear cake cannot be combined. Anyway, more statements (. h is generally only used to put the declaration, but not defined, see my book fixing "cross the road, look Around") also harmless, do not affect the compilation, why not?
Turn back and look at the top 3 questions, very good answer it?

Answer: not necessarily. This example is obviously superfluous. But if the functions in. c also need to call the same. C, then this. C will often include. h with the same name, so that there is no need to worry about the order of declarations and calls (the C language requires that it must be declared before it is used, and include has the same name.) h is usually placed at the beginning of. C. There are many projects that even use this notation as code specifications to standardize clear code.
Answer: 1 has already answered.
Answer: No. The person who asks this question is definitely unclear, or wants to mix water to touch fish. Very annoying is a lot of Chinese test out of this bad problem, for fear that others have a clear concept, absolutely to the examinee dizzy.

C program in the header file contains the essence of each other (reproduced)