Object-oriented special topics for C and C + + (3)--c++ in the non-elegant features

List of articles in this column

First, what is object-oriented

Second, C language can also achieve object-oriented

Third, the non-elegant features in C + +

Iv. solve the package and avoid the interface

V. Rational use of templates to avoid code redundancy

VI, C + + can also reflect

Vii. single-Case pattern solving the construction order puzzle of static member objects and global objects

Viii. more advanced preprocessor PHP

Third, the non-elegant features in C + +

Today, some of the problems that are not elegant in C + +, although C + + is an object-oriented design language, but there are many shortcomings and shortcomings, we will discuss how to solve these problems through good design.

C + + compilation Slow

C + + compiled slowly has become the industry consensus, a large C + + project Even with a dedicated server compiled for a long time to complete, Java and. NET as a large development platform, but also did not find the problem of compiling so slow, then what is the problem of C + + compilation difficult?

The tangle of templates

The problem with templates in C + + is that implementations and declarations must be referenced by the user, and the template code is valid, that is, the template is a code-generation mechanism that is expanded at compile time.

We might as well do an experiment, which is the declaration of the class:

template<classT>classCObject{public:    CObject(T k) {obj = k;}    ~CObject{}    TgetObj();private:    Tobj;};

The following is the implementation of the class:

#include "CObject.h"template<class T>TCObject<T>::getObj(){    return this->obj;}

Called in the main function:

#include <cstdio>#include "CObject.h"usingnamespacestd;int main(){    CObject<int> Obj(10);    int k = Obj.getObj();    printf("%d\n", k);    return0;}

Everything seems to be so smooth, but! My computer shows me the following error message:

Scanning dependencies of Target template_test[ -%] Building CXX Object cmakefiles/template_test. Dir/src/cobject. cpp. O[ -%] Building CXX Object cmakefiles/template_test. Dir/src/main. cpp. OLinking CXX executable Template_testcmakefiles/template_test. Dir/src/main. cpp. O: In the function ' main ':main.cpp:(. Text+0x22): Reference not defined for ' cobject<int>::getobj () 'collect2:ErrorLDReturned1Exit statusmake[2]: * * * [template_test] Error1make[1]: * * * [cmakefiles/template_test. Dir/ALL] Error2Make :[All] Error2

The linker tells me that we can't find a function called ' cobject::getobj () ', eh? Why, didn't we just put the class implementation link in?

If you're wrong about it, find a solution online and get a response like this:
#include "CObject.h"=#include "CObject.cpp"

OMG, I might as well put two files as a hpp to the convenience of, in fact, C + + is recommended that you do this, the reason is--the template is compiled, when used in the code to expand the resulting
If you do not do this, the linker will not find the corresponding code.

Then also found a lot of large projects such as boost library, why the direct cause of slow compilation, a large number of template deployment consumes huge resources, and template deployment is very bad for code reuse, the same algorithm, the other type, must all compile, generate new code, and such template generated code, Can not be compiled into a binary library in advance, so the result is, where the project changes a little, a lot of files repeatedly compiled, resulting in very slow compilation.

Problems with encapsulation

C + + classes are not very good at blocking the code, which, in contrast to the previous gobject, shows that the private variables of C + + are placed in the declaration of the class together, and we know that the declaration of a class is referenced by many other classes.
So, consider our C + + compilation process, Many classes refer to one. h file, then if this. h file changes, then all CPP files referencing this file will be triggered by repeated compilation, while we implement a class, the member functions of the class small repair is very common, but because the package is not thorough, then our project will be repeatedly compiled, resulting in a slow compilation.

Moreover, if it is a library, then the update of private members will even affect the user's use, very troublesome.
For example, the following code:

class Test {public:    Test();    ~Test();    void Show();private:    std::string message;    int pointer;    void formatMessage(std::string&);};

Obviously, the general C + + class, the private members will be more than the public members, then the private members to modify a little, even if only accidentally more space, will bring this file update, trigger makefile recompile, bring low efficiency.

Lack of reflex mechanism

The latest C++11 introduces many new features, including the use of the Auto keyword and template meta-programming features, but these can not compensate for the impact of missing reflection mechanism. Reflection is the core of the object serialization, GUI interface event response and dynamic call code according to the data, lack of reflection mechanism, will make C + + many places very inconvenient.

Many large-scale software, such as Firefox, in the implementation, often built a reflective framework for the system to use. But due to the problem of C + + itself syntax, lack of reflection still makes it difficult to write classes.

Cross-platform difficulties

C + + cross-platform is really bad, and even a lot of compilers will have a fantastic problem, for example, on different platforms, the size of the basic type will vary with the CPU word length, if there are cross-platform requirements of software, it is best to use cross-platform-defined types.
In C + + architecture, data tends to have memory alignment problems, and some compilers can set them up by compiler directives, which are best avoided by avoiding them.

When you cross-platform, you should also be careful about exception handling code, because some versions of the C + + compiler do not conform to specifications for thrown exception specifications.
In addition, the wide character set of different platforms is also a big problem, often can not be easily unified, in addition MinGW seemingly there is no wide character--

Object-oriented special topics for C and C + + (3)--c++ in the non-elegant features