C language incomplete type and delay definition

Always thought that my C language can still, although not superb, but at least more familiar with it. But a while ago read a tweet, and then Baidu a bit of C language is not the exact type. Found me. C language is not completely type and the use of a very wide range of delay definitions have no concept. These two days looked closely at the relevant concepts and experimented with the code.

This article is structured as follows:

• Introduction to the concept of non-complete type of C language
• A story
• Advantages of delay definitions
• Thinking...

C language Incomplete type

The incomplete type is the information of all types that do not know the variable. For example, you can declare an array, but not the length of the array, declare a pointer, but not the type of the pointer, declare a struct type, but do not give a complete definition of the struct, only that it is a struct. But in the end you have to give the complete type information. Otherwise the compilation will error. When the compiler compiles a cell, if it encounters a type or variable of a definition of an incomplete type (assuming it's called p), it treats that as normal, and then proceeds to compile the unit, and if it can't find the complete type information in this cell, it goes to the other compilation unit. If the entire compilation process is divided into compiling, linking two processes. It is normal to encounter an incomplete type during the compilation phase, but all incomplete types must have the corresponding complete type information in the link process, otherwise the error is incorrect.

For example, the following code first declares an array of variable characters of an incomplete type, str, without giving its length information. And then define the str array once, this time gives the length information.

Char str[];//incomplete type definition

Char str[10];//finally encountered the complete type information of the STR array, the compiler breathed a sigh of relief

Note: Incomplete type definitions do not fit into local variables, and symbolic redefinition errors occur if the above two lines are stacked in a function body.

An incomplete type cannot get its size by sizeof because it does not contain specific type information. (next to the compiler: I don't even know the full type of it, how do I tell you how big it is?) The following code cannot be compiled through. It will error error:invalid application of ' sizeof ' to an incomplete type cannot use sizeof on an incomplete type.

#include <stdio.h>

Char str[];

int n =sizeof (str);

Char str[10];

int main ()

{

printf ("%d", n);

return 0;

}

If you put int n = sizeof (str) behind CHARSTR[10] then it's OK.

Give an example of a struct again. The following code first declares a struct s of an incomplete type. The structure is then defined.

struct S;

struct s{

int A;

int b;

};

a story, an incomplete type of application: Delay definition

(Haha, finally to say the application, so excited!) ）

The non-complete type of C language is generally used as a modular programming. Now suppose you want to implement a stack of saved characters for your programmer teammates. So you write the following code.

Stack.h

typedef structnode{

char data;

struct node* next;

}node;

typedef struct {

node* top;//only requires a stack-top pointer

int num;

}stack;

/* In order to quickly return the number of elements in the stack, you use an int variable to record the number of elements in the stack, increment and decrement num when the stack is in and out, so that when the number of elements in the stack is returned, the NUM variable can be returned directly. */

/construct an empty stack s

Voidinitstack (Stack **s);

Destroy Stack S

Voiddestroystack (Stack **s);

Determine if the stack is empty

Intstackempty (Stack *s);

Returns the length of the stack

Intstacklength (Stack *s);

Returns the top element of the stack with E

int GetTop (Stack*s,char *e);

Into the stack

void Push (Stack*s,char e);

pops up the top element of the stack and returns its value with E

int Pop (Stack*s,char *e);

To not expose implementation details, you encapsulate the implementation code that implements the stack operation into a library file (both static and dynamic). The. h file and the library file are then confidently submitted to the teammates. and hinted to himself "I am really a cow x programmer, Mei will worship me, respect me, I can't stop!" No, I want to be humble, as if nothing happened. "

A few hours, the teammate came up frowning. You thought, "No, it's not the look of worship." Then there is the following conversation.

"What are you packing?" The number of elements in a stack is not statistically correct ", the teammates are angry

"How could that be?" In order to quickly return the number of elements in the stack, I purposely used an int variable to hold the number of elements in the stack "You are also very angry, obviously with a separate variable to save the number of elements is your proud place, incredibly was said wrong."

"I know, but it's not right," the teammate insisted that you were wrong.

Then, in order to find out the problem, you check with your teammates about the code he wrote. You find that he wrote the following code.

...

Push (s);

+ + (s->num);

...

Pop (s,&e);

--(S->num);

The original teammates in the stack and the stack s num has been added and reduced operation.

You: "Why are you moving my num?" ”

Teammate: "Isn't your num used to keep the number of elements in the stack?" I press the stack, out of the stack of course to increase or decrease it! ”

You: "I have done so in the implementation code." ”

The things you think you take for granted, your teammates are different from what you think. Then you tell him not to bother, NUM is the size of you to maintain. You can finally have fun together again.

But you still find some unpleasant code in your teammates ' code, which makes you feel like the diaphragm.

E =s->top->data;

int Len =s->num;

To get the top of the stack, he does not use the GetTop function you provide, but instead directly accesses the top pointer through the pointer directly from the stack. And instead of the Stacklength function you gave, you directly access the NUM member of the stack structure. Although you can communicate with him, let him not go to his own to access the details of your implementation. But you can't guarantee that he will listen to you completely. Can you solve this problem technically? Personally, team collaboration, can technically solve the matter, do not need to solve from the communication. This can reduce the cost of team communication. To get back to the question just now-can we solve the problem technically?

problem analysis and resolution methods

Look back at the code we just wrote. Teammates will have direct access to the internal details of our package because he sees a detailed definition of the structure in the. h file we give. Can you remove the definition of the stack struct in the. h file? Obviously not, because we are given a number of function interfaces to use the stack type of parameters, if the user does not see the definition of the stack, then how to define the stack type of variables and then passed to these interface functions? The answer is that we give the definition of the stack struct type, but not the details of the stack structure. That is, the incomplete type definition mentioned earlier. The improved code is as follows.

Stack.h

typedef structsqstack Stack;

... Each function Interface definition

Stack.c

typedef structnode{

char data;

struct node* next;

}node;

struct sqstack{

node* top;

int num;

};

In the improved code, we just define an incomplete type struct sqstack struct and use a typedef to equate it with the type of the stack name. The detailed definition of the sqstack structure is placed in the. c file. After submitting the. h file and library file to a teammate, he can no longer see the stack details. Under this, he had no direct access to the internal impulses of the structure. (How do you access it?) Honestly use the function interface provided by Brother! Teammates do not see how the internals of the stack structure are defined, and naturally do not know how to access them, and any access to the stack type pointer variable will cause the compiler to give an error. I don't have to worry about the stupidity of my teammates anymore.

As mentioned above, only the incomplete type of a struct is defined in the header file, and the detailed definition of the struct is deferred to a. c file in the form of a "deferred definition".

Other benefits of deferred definition

In the above example procedure, although we are to hide the implementation details before using the delay definition. But the delay definition also brings other benefits. Another benefit is that we can change the implementation at a very small cost of work. For example, we find that the implementation of the stack structure has bugs that need to be fixed, or we want to change the chained storage of the internal stack to sequential storage. I can modify it directly in the. c file and then recompile the build of the new library file without modifying the. h file because our interface functions do not need to be changed. By submitting the library file to the user, the user only needs to replace the old library file without modifying the code. In the case of a dynamic-link library, the user simply replaces the library file. In the case of a static library, the user simply re-links after replacing the library. The user does not need to modify the code and does not need to recompile their own client code.

If the delay definition is not used, the internal details are placed in the. h file, and the user's client code needs to be recompiled after the details are modified.

Advantages of delay definitions

Let's summarize the advantages of the delay definition:

1. Internal implementation details are hidden, forcing the user to access by interface rules. Reduce communication costs.

2. Easy to modify.

The above two points are required for modular programming. And personally think, standing in the customer's perspective, know less details the better, know more, to remember and think more things. Like the classic lines in a TV show: "Sometimes it's not good to know too much." The reason the character is killed is also "you know too much," or "You know what you shouldn't know." I only follow the established rules to access the code provided by others, there are questions directly to ask others, rather than see implementation code. Access according to established rules is also convenient for dividing responsibilities. If you want to summarize the 3rd benefit of the delay definition, it is personal: ease of division of responsibilities, clear responsibility boundaries.

Think ...

Q: Since the delay definition facilitates modular programming, is it useful in object-oriented languages such as C + +, Java, and similar techniques for delaying definitions?

A: Of course there is, but the object-oriented language is not called "delay definition". It is called encapsulation, access rights, interfaces, and polymorphism. The encapsulation and access rights of a class can prevent a customer from accessing the implementation details of a class, while interfaces and polymorphism can hide implementation details. Of course, they are not the only benefits.