SUMMARY

315

In fact, you’ll probably not find yourself implementing a copy constructor or assignment operator on Symbian OS very often. As I’ve explained, C class objects are not suitable for copy or assignment, while T class objects are ideal candidates for allowing the compiler to generate its own implicit versions. An R class object is unlikely to be copied and is safe for bitwise copy anyway. You would usually not expect to define an explicit copy constructor or assignment operator for an R class unless a shallow copy of the resource handle causes problems. For example, while the first object to call Close() releases the underlying resource and zeroes the handle value (making it invalid), a second object may still have a non-zero handle value. If the second object attempts to use the handle, even just to call Close(), the behavior is undefined and depends on the nature of the resource.

You can prevent a client copying objects of your R class by declaring the copy constructor and assignment operator private and not implementing them. If taking a copy is a valid action, you should declare and define the copy constructor and assignment operator, or provide another method, such as CloneL(), by which the resource handle is copied safely.

If your class does not need a destructor, for example because it has no cleanup code, you are under no obligation to add one. A good example of this is a T or R class, described in more detail in Chapter 1; neither type of class has need of an explicit destructor. For C classes, any compiler-generated destructor is virtual by default since the parent class, CBase, defines a virtual destructor. This means that, if your C class inherits from a class which defines a destructor, it is called correctly, regardless of whether you declare and define an empty destructor or allow the compiler to do it for you.

20.7 Summary

This chapter stressed the importance of defining classes clearly and comprehensively so that code is re-used rather than re-written or duplicated. It discussed a number of issues, most of which are not just specific to Symbian OS, but relate generally to C++ best practice, including:

•a comparison of the relative merits of passing and returning by value, reference or pointer

•the use of const where appropriate

•functional abstraction and how (not) to expose member data

•the use of enumerations to clarify the role of a function parameter and allow it to be extended in future

316	EXPOSE A COMPREHENSIVE AND COMPREHENSIBLE API

•the functions a compiler will generate for a class if they are not declared.

This chapter also discussed the use of IMPORT_C and EXPORT_C on Symbian OS to export API functions for use by external client code. The choice of when to export a function is relatively straightforward:

•Virtual functions should always be exported unless the class is nonderivable or where the functions are pure virtual (because there is no code to export, except in rare cases).

•Code which exports virtual functions must also export a constructor, even if it is empty, in order for the virtual function table to be created correctly. If necessary, the constructor should be specified as protected to prevent it being called directly by clients of the class.

•Inline functions should never be exported.

•Only functions that are used outside the DLL (called either directly or indirectly through a call from an inline function) should be exported.