Chapter 1

public: IMPORT_C TInt CreateLocal();
IMPORT_C void Cancel();
IMPORT_C void After(TRequestStatus& aStatus,
TTimeIntervalMicroSeconds32 anInterval);
IMPORT_C void At(TRequestStatus& aStatus,
const TTime& aTime);
IMPORT_C void Lock(TRequestStatus& aStatus,
TTimerLockSpec aLock);
};
The IMPORT_C macro says that the function must be imported from a DLL by the user of
that API. In the corresponding implementation, the function will be marked EXPORT_C, which
means that it will be exported from the DLL. A function without IMPORT_C is not exported
from its DLL and cannot, therefore, be part of the public API.
These macros are defined in e32def.h. Their implementations are compiler-dependent and
differ between CodeWarrior and GCC.
Virtual and inline functions don't need to be exported – they form a part of the API, even
without IMPORT_C in the header file.
If you're writing an API to be delivered in a DLL for use by other DLLs, you'll need to mark
your IMPORT_Cs and EXPORT_Cs carefully.
If you're not writing APIs – or you're not encapsulating them in DLLs for export – then you
needn't worry about how to use IMPORT_C and EXPORT_C. It's enough to understand what
they mean in Symbian OS SDK headers.
3.4.4 Virtual Functions and APIs
C++ isn't well designed for API delivery. There is no way to prevent further override of a
specific virtual function, and there is no way to guarantee that a function is not virtual without
looking down all the base classes to check for the virtual keyword. You can simulate
Java's final at the class level though, by making the constructor private.
C++'s access control specifiers aren't good for API delivery either. The meaning of public
is clear enough, but protected makes a distinction between derived classes and other
classes that doesn't put the boundary in the right place, since derivation is by no means the
most important vehicle for code reuse in OO. private is not private when it comes to virtual
functions: you can override private virtual functions whether or not this was intended by the
designer of an intermediate class (derived from a base class).
C++ has no language support for packaging APIs except classes and header files. So
Symbian had to invent its own rules for DLLs.
These design issues are most awkward when it comes to virtual functions. Best practice in
Symbian OS C++ includes the following guidelines:
� Declare a function virtual in the base class and in any derived class from which it is
intended to further derive and override (or implement) this function.