Why does some library header files only provide pre-declaration of classes without class definition?

1. Problem Introduction

In the field of program design, libraries can be said to be the basis of all programs. Almost none of today's programs are implemented from 0, more or less based on existing implementation function modules. These code modules that can be used by programmers with certain functions are called libraries.

Library usage can be roughly divided into two types, one is the use of source code level, and the other is the use of binary level.

For the first type, the source code of the library is completely open to users. Users can not only use it, but also understand the implementation principle of the library, and even modify the library to expand the function. In short, before the source code, no secret. The disadvantage of this method is that it is difficult for database developers to keep their intellectual property rights, let alone trade secrets; the next step is to re-compile the database for each Compilation Program, which requires more compilation connection time. At last, because everyone can modify it, it is easy to cause version confusion and it is not easy to maintain stable interfaces. Currently, there are many open source code libraries, such as QT, glibc, and GTK. However, most of them do not allow users to directly use the source code, but provide binary libraries with the source code for your reference.

For the second type, the Library only provides a limited description for users, so that users can use the library, but do not know the specific implementation of the library. The usage of this library is typically provided to the user's header file and. Lib binary file. The header file usually contains the prototype declaration and constant macro definition of the data structure declaration or definition and function, while the library file is the actual data structure and function implementation. (Note: For dynamically linked libraries, the link is only put to the running stage, and the principle is similar ). In this way, the user only knows the limited usage information, and the implementation of the library is invisible to the user. This has played a role in hiding implementations and has good support for protecting the intellectual property rights of database manufacturers. After all, it is difficult to analyze the implementation of databases through reverse engineering.

This article focuses on the implementation principle of the library that can be used in the second way, focusing on how to hide more information to users without affecting their use.

2. Information to be hidden

For users, the Library is the header file (containing the data structure definition and function declaration) + (with the export symbol) binary implementation file.

So there are only two places to hide: header file and binary file.

What needs to be hidden is mainly the data structure definition, function name (or Declaration), and function implementation.

The so-called hiding refers to the hiding of Symbol names, data structures, and algorithms in the source code.

(1) Implement functions. The source code is automatically hidden because it has been compiled into binary, and no trace of source code is found in the library to implement these operations. In the header file, the function implementation code is not likely to appear.

(2) Name and prototype of a function. The binary library does not have a prototype declaration. function names may only exist in the export table. The header file may have function declarations. There is a dependency problem. That is, the function name in the binary file export symbol table is the premise that the header file has the function prototype declaration. Normally, only a portion of the function names in the export table are declared in the header file and are not declared. The function names are mainly used by the library vendor for development and usage, and cannot be directly used by users. This is widespread in the Windows API library, and Microsoft has been condemned by many people, because Microsoft can use more library functions than others. The same is true for the Vega library. Although the exported symbol table of the library contains a large number of functions, including C ++ member functions, C functions, however, the header file provided to the user does not contain the declaration of some C functions and the definition of most C ++ classes (Note: C ++ member functions cannot be separately declared, must be declared through the definition of the entire class ). Therefore, you can only use limited C functions for development, rather than C ++ interfaces. Vegstmme is obviously more open. It provides users with a large number of C ++ class interfaces, and exposes the data structure types of their databases.

If the function is declared in the header file and there is no response symbol in the Database Export table, this function cannot be used because the function cannot be found during connection.

(3) definitions of data structures. Data Structures in C mainly refer to struct and communities, and are mainly classes in C ++. Whether to open the definition of these data structures to users depends on the database vendor. If you are allowed to directly operate on the data structure, such as assigning values to its members and calling its member functions, you must open its definition to the user. The compiler must know the memory layout of the data structure when compiling such operations, and the memory layout is only known through its definition. In this regard, the typical library is MFC, which allows users to directly use their classes to create objects and call their member functions. Therefore, many class definitions exist in the header files provided to users.

However, if you are not allowed to operate on the data structure directly, you can hide the definition of the data structure by providing a set of functions to operate on the data structure. The header file provided to the user does not need to contain the definition of the data structure. You only need to provide the pre-declaration, such as class clibclass; or struct student; the data structure type cannot appear in the function parameters that operate these data structures, because if so, the compiler needs to perform the stack pressure operation based on the memory layout of the data structure. Instead, the pointer type of the data structure should be used as the parameter type. This is because the compiler has the same number of bytes (such as 4 bytes) No matter what type of pointer parameter is used in the stack operation ). As for pointer types, they are all completed in function implementation. In principle, when a pointer parameter can be declared in the function declaration, it can be of any type. This is because you can convert the type in the function implementation. However, C ++ does not work because the compiled function name is related to the parameter type. If the function declaration and function definition use different types of pointer types, the compiled function names are different, so the function names cannot be found during the link. For C language, the compiled function name has nothing to do with the parameter type. Therefore, the parameter type in the function declaration can be different from the parameter type during implementation. That is to say, when you declare a struct in advance, you can take any name, such as the header file:

Struct sanyname;

Extern funtionlib (struct sanyname * P );

The implementation file:

Struct student

{

Int age;

Double score;

}

Funtionlib (struct student * P) // automatic pointer type conversion

{

P-> age = 20;

P-> score = 88.5;

}

This not only hides the implementation of the data structure, but also hides the real name of the data structure. Of course, this is not necessary.

3. Why does the Vega header file only have class vgwindow, but does not have vgwindow definition?

I believe that readers who have used the Vega library have had similar questions: the VG. h header file only has the class vgwindow;-like pre-class declaration, but does not see the definition of the vgwindow class. Readers do not know what vgwindow members are. I believe you have understood it, because using the root of the Vega library does not require (or do not want to) the user to know the internal structure of the class. Because the class is a concept in C ++, therefore, the pre-declared class name should be consistent with that in the Vega library. Here, class vgwindow; the only function is to make the modified name of the function consistent with the exported symbol of the library when the compiler compiles the function.