The usage of private inheritance in cross-platform

Currently, the mainstream C ++ development environments on mobile platforms include Windows Mobile, Symbian, brew, and Linux. To accelerate the development of applications on various platforms, the common method is to build a cross-platform framework ). So many platform-independent code sharing will undoubtedly accelerate development. Now the key question is how to achieve this platform abstraction layer.

We have seen a lot of code similar to the following:

/* <Br/> * salthread. H -- declare of a Sal thead <br/> * scanlife <br/> * created by chunyuan on 07/13/2009. <br/> * Copyright 2009 scanbuy Inc. all rights reserved. <br/> */<br/> # ifndef _ sal_thread_h _ <br/> # DEFINE _ sal_thread_h _ <br/> # ifdef symbian_sal <br/> # include <e32std. h> <br/> # Elif defined wm_sal <br/> # Elif defined brew_sal <br/> # include "aeethread. H "<br/> # endif <br/> # inclu De "saldef. H "<br/> namespace Sal <br/> {<br/> typedef sint32 (* sthreadfunc) (void * pdata ); </P> <p> class salthread <br/> {<br/> Public: </P> <p> salthread (); <br/> // creates a thread. call start () to start it. <br/> ~ Salthread (); <br/> // destroys the thread. </P> <p> # ifdef wm_sal <br/> handlem_hthread; <br/> # Elif defined symbian_sal <br/> rthreadm_hthread; <br/> # Elif defined brew_sal <br/> ithread * m_pthread; <br/> # endif <br/>}; <br/>}

After this is done, we can. in CPP, different macros symbian_sal and wm_sal are used to separate the implementation, or three different CPP, such as salthread_bre1_cpp and salthread_symbian.cpp... In this way, each platform can find the header file and the corresponding CPP to compile. In fact, this is the case in many places, including some large C ++ cross-platform libraries. But with the development going deeper, we obviously feel the pressure.

First, if the programmer is not very familiar with some features, the platform-related content will be left in the public part! For example, a brew programmer accidentally adds the thread name to the public header file.

Aechar m_pwszthreadname [100];

In this way, his own code has been compiled, okay has been run, and check in code. But the Symbian. Windows Mobile Code has an error !!! I don't know what to do.

Second, as the platform increases, the header file of salthread. H is always modified in the # include region and class member.

In this way, the code will gradually become

# Ifndef _ sal_thread_h _ <br/> # DEFINE _ sal_thread_h _ <br/> # ifdef symbian_sal <br/> # include <e32std. h> <br/> # Elif defined wm_sal <br/> # Elif defined brew_sal <br/> # include "aeethread. H "<br/> # Elif defined posix_sal <br/> # include <pthread. h> <br/> # Elif defined osp_sal <br/> # include <fthread. h> <br/> # endif <br/> # include "saldef. H "<br/> namespace Sal <br/> {<br/> typedef sint32 (* sthreadfunc) (void * pdata); </P> <p> # ifdef wm_sal <br/> typedef XXX critical; <br/> # Elif defined symbian_sal <br/> typedef YYY critical; <br/> # Elif defined brew_sal <br/> typedef ZZZ critical; <br/> # Elif defined osp_sal <br/> typedef uuu critical; <br/> # Elif defined linux_sal <br/> typedef vvv critical; <br/> # endif </P> <p> class salthread <br/> {<br/> Public: </P> <p> salthread (); <br/> // creates a thread. call start () to start it. <B R/> ~ Salthread (); <br/> // destroys the thread. </P> <p> # ifdef wm_sal <br/> handlem_hthread; <br/> # Elif defined symbian_sal <br/> rthreadm_hthread; <br/> # Elif defined brew_sal <br/> ithread * m_pthread; <br/> # Elif defined osp_sal <br/> OSP: runtime: thread * m_pthread; <br/> # Elif defined linux_sal <br/> pthread_t m_thread; <br/> # endif <br/>}; <br/>}

This is not an alarmist, but a true and repeated display in our daily development. The addition of this header file on the platform turns this header file into a minefield. If you do not pay attention to the modification, it will make other platforms unable to work. It takes a lot of time to debug the file correctly!

 

How can we change this situation? Private inheritance helped us well at this time. Let's take a look at the wonderful descriptions in the C ++ FAQ:

Private
Inheritance is a syntactic variant of composition (aka aggregation and/or has-).

E. g.,"Car
Has-Engine
"Relationship can be expressed using
Simple Composition
:

Class engine {<br/> Public: <br/> engine (INT numcylinders); <br/> void start (); // starts this engine <br/> }; </P> <p> class car {<br/> Public: <br/> Car (): E _ (8) {}// initializes this car with 8 cylinders <br/> void start () {e _. start () ;}// start this car by starting its engine <br/> PRIVATE: <br/> engine E _; // car has-a engine <br/> };

The"Car
Has-Engine
"Relationship can also be expressed using
Private
Inheritance
:

Class car: Private engine {// car has-a engine <br/> Public: <br/> Car (): Engine (8) {}// initializes this car with 8 cylinders <br/> using engine: Start; // start this car by starting its engine <br/> };We can see that private inheritance actually provides a relationship with has a, which is very easy. We can use it in our environment! For example, in this case, we have a head file salthread. H. This header file is changed to the following mode: # Ifndef _ sal_thread_h _ <br/> # DEFINE _ sal_thread_h _ <br/> # ifdef symbian_sal <br/> # include "salthread_s60.h" <br/> # Elif defined wm_sal <br /># include "salthread_wm.h" <br/> # Elif defined brew_sal <br/> # include "salthread_bre1_h" <br/> # Elif defined posix_sal <br/> # include "salthread_posix.h "<br/> # Elif defined osp_sal <br/> # include" salthread_osp.h "<br/> # endif <br/> # include" saldef. H "<br/> namespace SA L <br/>{< br/> typedef sint32 (* sthreadfunc) (void * pdata); </P> <p> class salthread: private salthreadimpl <br/>{< br/> Public: </P> <p> salthread (); <br/> // creates a thread. call start () to start it. <br/> ~ Salthread (); <br/> // destroys the thread. <br/> sbool startthread (sthreadfunc PFN, void * data); <br/> sbool exitthread (); <br/>}; </P> <p> sbool salthread:: startthread (sthreadfunc PFN, void * Data) <br/>{< br/> startthreadimpl (PFN, data); <br/>}< br/> sbool salthread :: exitthread () <br/>{< br/> exitthreadimpl (); <br/>}</P> <p>}The first positive change here is that our different macro definitions are put in one place. There is only one place where there is something different from the platform, that is, those # include here, except this place, other platform-related things won't appear here! In addition, the salthread private inherits the salthreadimpl class. Naturally, we transferred these platform relevance to the header files related to each platform. At this time, my salthread_wm.h can be written like this: Namespace Sal <br/>{< br/> class salthreadimpl <br/>{< br/> Public: </P> <p> salthreadimpl (); <br/> ~ Salthreadimpl (); <br/> sbool startthreadimpl (sthreadfunc PFN, void * data); <br/> sbool exitthreadimpl (); </P> <p> protected: <br/> handle hthread; <br/>}< br/>}

At this time, salthread_s60.h and salthread_brew.h each have their own small world, and obviously they will not fight any more !! This includes defining a typedef and not having to write it in one place with others, because this place only belongs to you! In this way, the code modification of the platform-related programs will not affect others as much as possible.

To sum up, our traditional mode is salthread. H, which corresponds to salthread_wm.cpp, salthread_s60.cpp, and salthread_posix.cpp. In this way, the related information of our Platform Declaration is in salthread. h, so our modifications bring about a lot of insecurity. Our new model is salthread. h corresponds to salthread_wm.h, salthread_wm.cpp, salthread_s60.h, salthread_s60.cpp. in this way, we provide abstract interfaces through salthread, and salthread_xx.h helps us define the platform features. We have to say that it is an improvement in the previous implementation!