Use special features to achieve polymorphism-External Polymorphism

A pair of operations, such as new and delete, malloc, and free, or all custom operations, such as lock and unlock, are usually encountered in the project.

For new, STL contains auto_ptr, which sometimes achieves a similar auto_ptr for every pair of objects and is not worth the candle, and violates the purpose of C ++ reuse.

The code below is a solution to the above problem:

Class A {public: void lock () {printf ("A: Lock \ n");} void unlock () {printf (":: unlock \ n ") ;}}; Class B {public: void before () {printf (" B: Before \ n ");} void after () {printf ("B: After \ n") ;}}; class c {public :}; template <class T> class guard_adapter_t {public: guard_adapter_t (T & D ): d _ (d) {enter ();}~ Guard_adapter_t () {leave ();} void enter (); void leave (); Private: T & D _ ;}; template <> void guard_adapter_t <a> :: enter () {d _. lock ();} template <> void guard_adapter_t <a >:: leave () {d _. unlock () ;}template <> void guard_adapter_t <B >:: enter () {d _. before ();} template <> void guard_adapter_t <B >:: leave () {d _. after ();} int _ tmain (INT argc, _ tchar * argv []) {A; guard_adapter_t <A> d1 (a); B; guard_adapter_t <B> D2 (B); // external symbols that cannot be parsed // C; // guard_1 <C> D3 (c); Return 0 ;}

 

The academic site is called "external polymorphism (external-polymorphism )"

The purpose of external polymorphism is:

C ++ classes without inheritance relationships and/or virtual functions are allowed to be used by polymorphism. These unrelated classes can be used in a unified manner by their software.

Motivation:

It is difficult for C ++ classes from different sources to work together. Applications often need these classes to "reflect" certain public behaviors, but they are limited by the existing design of these classes. If only the class interface needs to be adapted, an obvious solution is to use the object structure pattern such as adapter or decorator [1. Sometimes you may encounter more complex requirements, such as changing the following interfaces and implementations. In this case, the behavior of these classes may be required as if they have a public base class.
For example, imagine that we are debugging an application built by C ++ classes from different libraries, it can easily output the internal status of any object to a file in a readable format or display it on the console. It can even put all existing class instances in a set and traverse the set so that each instance can output its own information.
Because the elements in the set are of the same class, a public base class is required to maintain a set. However, these classes have been designed, implemented, and used, and we cannot choose to modify the inheritance tree and introduce a public base class-we may not be able to access the source code. In addition, classes in OO languages such as C ++ belong to the specific data type (concrete date type) [2], which requires a precise storage pattern, cannot include some hidden pointers (such as the virtual function table pointer of C ++ ). It is not feasible to re-implement these classes with a common polymorphism base class.
Therefore, solutions that make irrelevant classes reflect public behavior must meet the following mandatory constraints:
1. space efficiency-the solution cannot affect the storage pattern of existing objects. In particular, classes without virtual functions (for example, specific data types) cannot be forcibly added to a virtual function table pointer.
2. polymorphism-all database objects must be accessible in a uniform and transparent manner. Especially when the new class is added to the system, we do not need to modify the existing code.

 

Refer:

Http://blog.csdn.net/waitan/article/details/1537983