Wiley.Symbian.OS.C.plus.plus.for.Mobile.Phones.Aug.2007 (779890), страница 11
Текст из файла (страница 11)
Moreover, as in Objective-C,the cleanup stack mechanism does not cater by default for stack-allocatedobjects, whereas in ISO C++ all stack-allocated object destructors arecalled when an exception is thrown. This latter point, although anapparent limitation, makes throwing of exceptions much more efficient.On Symbian OS, this was included by design, because the stack isquite small (and doesn’t grow dynamically). Thus, in Symbian OS, stackallocation of complex objects that own other resources, and hence needdestructors, is in most cases not recommended.Symbian OS C++ Naming ConventionsBecause of the inefficiency of exceptions handling, and the need to bein complete control of a C++ object’s lifecycle, Symbian chose a C++naming standard that expresses both object ownership and exceptionthrowing (leaving) behavior.
This standard is based on the Taligent codingstandard [Taligent 1994].In Symbian OS C++, the presence or absence of a trailing L ina method name tells you whether this method may leave (throw anexception) or not. This paradigm has immense value because it explicitlycommunicates to the user of a method the need to guard against anyexceptions, and thus to keep track of objects that may need to cleanup their resources. Similarly, starting identifier names with a prefix suchas i or a communicates the scope of the corresponding objects to theprogrammer.The coding standard is discussed in detail in Chapter 3.2.3 APIs Covered in this BookSymbian OS APIs are divided into categories that correspond to thedifferent types of program:• the kernel exposes an API through the executive calls of the userlibraryAPIS COVERED IN THIS BOOK37• system servers expose APIs through their client interfaces• application engines expose APIs to the applications that use them• middleware components are APIs in perhaps the purest and simplestsense• other API types, such as device drivers, sockets protocol implementations, and printer drivers, are associated with particular systemcomponents.These divide into several broad groupings:GroupDescriptionBaseProvides the fundamental APIs for all of SymbianOS.MiddlewareGraphics, data, and other components to supportthe GUI, engines, and applications.UIThe system GUI framework.ApplicationsApplication software can be divided into GUI parts(which use UIQ) and engines (which don’t dealwith graphics).
Some applications are simply thinlayers over middleware components; others havesubstantial engines.CommunicationsIndustry-standard communications protocols forserial and sockets-based communication, dial-upnetworking, TCP/IP, and infrared.Language systems The Java run-time environment.Symbian OSConnectCommunications protocols to connect to a PC, andservices such as file format conversion, datasynchronization for contacts, schedule entries ande-mail, clipboard synchronization, and printing to aPC-based printer.The following table shows the main C++ APIs that we will be coveringin this book, and introduces the naming conventions that we use.
Thenames include:• a friendly title, which we’ll normally use in the book unless there is aneed to be more precise• the shared library name: add .dll to this for the name of the DLLto use at run time, or add .lib for the name of the import library tospecify in your MMP file38A SYSTEM INTRODUCTION TO SYMBIAN OS• the top-level project name in the source tree: this is the main systemused internally by Symbian to refer to APIs, and usually correspondsto the shared library name. This is not always the case, since someprojects produce more than one library, while others produce noneat all.For good measure the table includes a group category (base, middleware etc.) for each API.The corresponding header files, with the names listed in the table,are located in the \epoc32\include directory.
The Symbian OS Cstandard library is an exception to this rule, as its header files are isolatedin their own directory, \epoc32\include\libc .TitleDLLSourceGroupUser libraryeuserE32BaseFile serverefsrvF32BaseHeaderse32def.h,e32std.h,e32base.h,e32*.hUtility and kernel-object APIs. See Chapter 4 forresource cleanup, Chapter 5 for strings and descriptors,Chapter 6 for active objects, and Chapter 8 for theclient–server framework.F32file.hFile and device management. See Chapter 7.GDIgdiGDIMiddlewaregdi.hAbstract graphical device interface.
See Chapter 12 foran introduction to drawing, and Chapters 17 and 18 forother facilities, with the emphasis on deviceindependence.Windowserverws32WSERVMiddleware w32std.hShares screen, keyboard and pointer between allapplications. See Chapters 17 and 18.CONEconeCONEMiddlewarecoe*.hControl environment: works with window server toenable applications to use controls. See Chapters 17and 18.Stream storeestorSTOREMiddlewareStream and store framework and mainimplementations.
See Chapter 7.s32*.hSUMMARYTitleDLLResourcefilesbaflBAFLMiddleware ba*.hOnce grandly titled ‘basic application frameworklibrary’, its most useful aspect is resource files, though italso contains other APIs. See Chapter 13.ApplicationarchitectureapparcAPPARCMiddleware apa*.hGoverns file formats and application launching. SeeChapters 9 and 11.Qikon/Avkon qik*/and Uikonavk*uik*Source39GroupQIKON/UIAVKON,UIKON andothersHeadersqik*.h/akn*.heik*.hThe system GUI. Qikon and Avkon provideUIQ-specific and S60-specific layers over Uikon.SocketsserveresockESOCKCommses_*.hSockets-based communications using protocols such asTCP/IP, infrared and others. See Chapter 19.TelephonyserveretelETELCommsetel*.hVoice, data, address book etc.
on landline or mobilephones and modems. See Chapter 20.While this book gives you a head start on the main APIs, it cannotprovide detailed information on every Symbian OS API. The SDKs containmuch additional valuable information and advice.SummaryIn this chapter we discussed the fundamentals of Symbian OS, coveringthe basic principles of both the operating system and the framework thatencompasses it.We looked at the distinct features that the Symbian OS EKA2 architecture borrows from microkernel, nanokernel and monolithic kernelphilosophies. We also described the multi-threaded nature of the Symbian OS kernel and how programs access it by means of executivecalls.We examined the Symbian OS process model and memory management, and how Symbian OS servers communicate with clients throughIPC.
In addition, we discussed shared libraries and their distinction, basedon the interface they provide.40A SYSTEM INTRODUCTION TO SYMBIAN OSThen we introduced a major Symbian OS C++ paradigm, that of activeobjects, and how concurrency is introduced in the C++ environment. Wealso looked at one of the most important idioms, that of Symbian OS C++exceptions handling.Finally we summarized the main APIs that are covered in this book,showing the broad groupings into which they fall.3Symbian OS C++In the previous two chapters, we have looked at the fundamental conceptual elements of Symbian OS.
The purpose of this chapter is to take alook at how Symbian OS approaches aspects of design and programmingin C++.The fundamental design decisions of Symbian OS were taken in1994–5 and its toolchain for emulator and ARM builds was essentiallystable by early 1996. Since then the compilers have changed, but thecoding style still bears the hallmarks of the early GCC and MicrosoftVisual C++ compilers.3.1 Fundamental Data TypesLet’s start with the basic types.
e32def.h (in \epoc32\include)contains definitions for 8-, 16- and 32-bit integers and some other basictypes that map onto underlying C++ types such as unsigned int, whichare guaranteed to be the same regardless of the C++ implementation used(see Table 3.1).For integers, use TInt unless you have good reason not to. Useunsigned integer types only for flags, or if you know exactly whatyou’re doing with unsigned types in C++.
Use specific integer widthswhen exchanging with external formats or when space optimization isparamount. TInt64 is also available; it is a class defined in e32std.h,rather than a typedef. There is no TUint64.Do not use floating-point types unless you have to. Machines runningSymbian OS do not usually include hardware floating-point units, sofloating-point operations are much slower than integer operations.
Mostroutine calculations in Symbian OS GUI or communications programs42SYMBIAN OS C++Table 3.1 Data types.Related typesDescriptionTInt8, TUint8Signed and unsigned 8-bit integersTInt16, TUint16Signed and unsigned 16-bit integersTInt32, TUint32Signed and unsigned 32-bit integersTInt, TUintSigned and unsigned integers: in practice, thismeans a 32-bit integerTReal32, TReal64,TRealSingle- and double-precision IEEE 754floating-point numbers (equates to float anddouble); TReal equates to TReal64TText8, TText16Narrow (ASCII) and wide (Unicode) characters(equates to unsigned char and unsignedshort int)TBoolBoolean – equates to int due to the earlycompilers used; some code depends on this soit has not been changed with the newcompilersTAnyEquates to void and usually used as TAny* (a‘pointer to anything’)can be done by using integers.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
