Symbian OS Explained Effective C++ Programming for Smartphones phần 10 ppt

Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Appendix Code Checklist The following list is based on the internal Symbian Peer Review Checklist. Declaration of Classes • A class should have a clear purpose, design and API. • An exported API class should have some private reserved declarations for future backward compatibility purposes. • The API should provide the appropriate level of encapsulation, i.e. member data hiding. • Friendship of a class should be kept to a minimum in order to preserve encapsulation. • Polymorphism should be used appropriately and correctly. • A class should not have exported inline methods. • A non-derivable class with two-phase construction should make its constructors and ConstructL() private. • const should be used where possible and appropriate. • Overloaded methods should be used in preference to default param- eters. • Each C class should inherit from only one other C class and have CBase as the eventual base class. • Each T class should have only stack-based member variables. • Each M class should have no member data. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 334 CODE CHECKLIST Header Files • Header files should contain ”in-source” documentation of the purpose of each class. • The inclusion of other header files should be minimized by using forward declaration if required. • Header files should include the correct #ifndef #define #endif directive to prevent multiple inclusion. • The number of IMPORT_C tags should match the corresponding EXPORT_C tags in the .cpp file. Comments • Comments should match the code. • Comments should be accurate, relevant, concise and useful. • Each class should have ”in-source” documentation of its purpose in header file. • Each method should have ”in-source” documentation of its purpose, parameters and return values in the .cpp file. Constructors • A CBase-derived class does not need explicit initialization. • Member data of T and R classes should be explicitly initialized before use. • Member data should be initialized in the initializer list as opposed to the body. • A C++ constructor should not call a method that may leave. • Two-phase construction should be used if construction can fail with anything other than KErrNoMemory. • NewL() and NewLC() methods should wrap allocation and con- struction where necessary. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com CODE CHECKLIST 335 Destructors • All heap-allocated member data owned by the class should be deleted. • There should be a NULL pointer check before any dereference of a member pointer. • Member pointers do not need to be set to NULL after deletion in the destructor. • Member pointers deleted outside the destructor should be set to NULL or immediately re-assigned another value. • A destructor should not leave. Allocation and Deletion • For a new expression, either use new (ELeave), or check the return value against NULL if leaving is not appropriate. • For a call to User::Alloc(), either use AllocL(), or check the return value against NULL if leaving is not appropriate. • Objects being deleted should not be on the cleanup stack or referenced by other objects. • C++ arrays should be de-allocated using the array deletion operator, delete [] <array>. • Objects should be de-allocated using delete <object>. • Other memory should be de-allocated using the method User::Free (<memory>). Cleanup Stack and Leave Safety • If a leaving method is called during an object’s lifetime, then the object should either be pushed on to the cleanup stack or be held as a member variable pointer in another class that is itself leave- safe. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 336 CODE CHECKLIST • An object should not simultaneously be owned by another object and held on the cleanup stack when a leaving method is called. • Calls to CleanupStack::PushL() and CleanupStack::Pop() should be balanced (look out for functions that leave objects on the cleanup stack, such as NewLC()). • If possible, use the CleanupStack::Pop() and PopAndDe- stroy() methods which take pointer parameters, because they catch an unbalanced cleanup stack quickly. • Where possible, use CleanupStack::PopAndDestroy() rather than Pop() followed by delete or Close(). • Local R objects should be put on the cleanup stack using Cleanup- ClosePushL(), usually after the object has been ”opened”. • Errors caught by a TRAP harness that are ignored must be clearly commented and explained. • The code within a TRAP harness should be able to leave. • Error processing after a TRAP that ends with an unconditional User::Leave() with the same error code should be re-coded using the cleanup stack. • Use the LeaveScan tool to check source code for functions that can leave but have no trailing L. Loops and Program Flow Control • All loops should terminate for all possible inputs. • The bracing should be correct on if else statements. • Optimize loops by using the clearest type (do while or while)in each case. • There should be a break statement for each case of a switch statement – or a comment if a flow-through to the next case statement is meant. • A switch statement shouldn’t contain case statements that return from the function unless every case in that switch statement con- tains a return. • A switch statement should be used to indicate state control. Each case statement should contain only a small amount of code; large chunks of code should be moved into separate functions to maintain the readability of the switch statement. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com CODE CHECKLIST 337 • There should be a default in every switch statement. • Flow control statements should be used rather than extra boolean variables to manage program flow. Program Logic • Stack usage should be reasonable, i.e. don’t store large objects on the stack. • Errors should propagate properly and not be changed or remapped to e.g. KErrGeneral. • Pointers should be manipulated and accessed correctly, i.e. check for invalid address access, pointer overflow, etc. • Bitmasks should be used properly (& to read, | to set, ∼ to reset). • Unexpected events and inputs should be handled gracefully, i.e. use error returns, leaves or panics appropriately. • Hard-coded ”magic” values should not be used. • Logging statements should be informative and in useful places. • Code should be efficient, e.g. do not copy things unnecessarily, do not create too many temporaries, do not use inefficient algorithms. • Casts should be in C++ style such as static_cast, reinter- pret_cast or const_cast rather than in C s tyle. • A cast should only be used where absolutely necessary and should be the correct type for the expression. Descriptors • Descriptor character size should be correct, i.e. 8 bits for binary data and ASCII-like text; 16 bits for explicitly Unicode text; no suffix for normal text. • _L should not be used for literal data: use _LIT instead (except for test code, etc.). • Assignment to TPtr or TPtrC does not redirect the pointer; Set() is required for that purpose. • HBufC::Des() and TBufC::Des() are not required to use the object as an unwritable descriptor. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 338 CODE CHECKLIST • HBufC::Des() and TBufC::Des() are not required for assign- ment: these classes define assignment operators. • Use AppendNum() or Num() to format a number instead of TDes::AppendFormat() or Format(). • Use Append() instead of TDes::AppendFormat() or Format() to concatenate strings. • Arguments to TDes::AppendFormat() or Format() should match the format of the string and the descriptor must be passed by pointer. • Use descriptor functions such as Find() and Locate() rather than re-implementing this functionality. • Iterating over a descriptor using operator[] is expensive; con- sider using C++ pointer arithmetic and the TDesC::Ptr() func- tion instead. • Descriptors passed to asynchronous operations should persist until the operation completes, e.g. do not use a stack-allocated descriptor. Containers • The least-derived type of container should be used in declarations. • The initial size and granularity of the container should be appropriate. • All owned objects in the container should be destroyed (or ownership passed) before the container is destroyed. • The appropriate container for the purpose should be used. • Thin templates should be used for any templated code. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Glossary Term Definition Chapter active object Responsible for issuing requests to asynchronous service providers and handling those requests on completion. Derives from CActive. 8, 9 active scheduler Responsible for scheduling events to the active objects in an event-handling program. 8, 9 asynchronous service provider A system, component or class, which provides a service asynchronously, typically to an active object. Asynchronous requests are indicated by function calls with a TRequestStatus reference parameter. 8, 9 backward compatibility Updating a component in such a way that client code which used the original version can continue to work with the updated version. See also forward compatibility. 18 binary compatibility Modifying a library in such a way that code which linked against the previous version can continue to run with the new version without needing recompilation. 18 C function In the context of Symbian OS, this refers to a function with a trailing C in its name, e.g. NewLC(). If successful, this type of function leaves one or more objects on the cleanup stack when it returns. 3 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 340 GLOSSARY Term Definition Chapter chunk A unit of memory allocation, where a linear region of RAM is mapped into contiguous logical addresses. 13 clanger The Clangers are a race of highly-civilized, small, bright pink, long-nosed, mouse-shaped persons who stand upright on big flappy feet (see www.clangers.co.uk for more information). throughout cleanup stack Takes responsibility for cleaning up the objects pushed onto it if a leave occurs. 3 client interface function A member function in a client-side session (or subsession) class that sends a specific message request to a server, identified by an opcode. 11, 12 context switch A switch in execution between one thread or process and another. This involves saving the context of the currently executing thread or process (i.e. its address space mappings) and restoring the context of the newly executing thread or process. 10, 11, 12 descriptor A string, so-called because it is self-describing. All descriptor classes derive from TDesC, which describes an area of memory used as either a string or binary data. 4, 5 descriptorize To marshal a flat data object, typically a struct or T class, into a descriptor for inter-thread data transfer. 6, 11, 12 DLL (dynamic link library) Dynamic link libraries contain functions that are linked and stored separately from the programs that use them. 13 DLL export table An area in the DLL which lists the DLL addresses of exported items. On Symbian OS, these items are indexed by ordinal. 13 E32 Collective term for the base components of Symbian OS. ECOM A generic framework in Symbian OS from v7.0 for use with plug-in modules. 14 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com GLOSSARY 341 Term Definition Chapter emulator An implementation of Symbian OS hosted on a PC running Microsoft Windows. Compare with target hardware. 13 entry point A function called when a DLL is loaded or attached by a thread or process. In Symbian OS, the function E32Dll() is usually coded as the entry point. 13 EPOC, EPOC32 Earlier names for Symbian OS. Rumors that this stood for ‘Electronic Piece of Cheese’ are unconfirmed. exec call A call to the kernel via a software interrupt (see this useful paper by John Pagonis for more details www.symbian.com/developer/ techlib/papers/userland/userland.pdf ) 10 F32 Collective term for the components making up the Symbian OS file server. FEP (Front-End Processor) Allows the input of characters by a user, for example, by handwriting recognition or voice, and converts the input transparently into text. 13 file server The server thread that mediates all file system operations. All application programs that use files are clients of this thread. 11 flat buffer A dynamic buffer using flat storage, i.e. a single segment of memory (see also segmented buffer). 7 forward compatibility Updating a component in such a way that code which works with the new version also works with the original version. See also backward compatibility. 18 framework A component that allows its functionality to be extended by plug-in modules, sometimes known as framework extensions. The framework loads the extensions as required at runtime. 13, 14 framework extension Provides plug-in functionality to a framework, typically by implementing interfaces defined by that framework. On Symbian OS, a framework extension is implemented as a polymorphic DLL. 14 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com [...]... 04708 7108 3 Martin Tasker, Jonathan Allin, Jonathan Dixon, Mark Shackman, Tim Richardson and John Forrest (2000) Professional Symbian Programming: Mobile Solutions on the EPOC Platform Publisher: Wrox Press ISBN: 18 6100 303X Leigh Edwards and Richard Barker (2004) Developing Series 60 Applications: A Guide for Symbian OS C++ Developers Publisher: Addison Wesley ISBN: 0321227220 J Jipping (2002) Symbian OS. .. character codes for a wide range of languages 5, 6 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Bibliography and Online Resources Books on Symbian OS Richard Harrison (2003) Symbian OS C++ for Mobile Phones Publisher: John Wiley and Sons Ltd ISBN: 0470856114 Richard Harrison (2004) Symbian OS C++ for Mobile... Exceptional C++ Publisher: Addison Wesley ISBN: 0201615622 Symbian OS on the Internet Symbian Press Website www .symbian. com/books Symbian Developer Network www .symbian. com/developer Symbian Developer Network Support Forums www .symbian. com/developer/public/index.html BIBLIOGRAPHY AND - http://www.simpopdf.com 349 Simpo PDF Merge and Split Unregistered Version ONLINE RESOURCES Jo Stichbury’s website www.WhoShavesTheBarber.com... handset running Symbian OS (compare with emulator) 10, 13 thin template An idiom used to minimize code bloat from the use of standard C++ templates 19 thread-local storage (TLS) A machine word of memory that may be used to anchor information in the context of a DLL or a thread Used instead of writable static data, which is not supported for Symbian OS DLLs 13 TRAP, TRAPD Trap harness macros within which... tests 273–6 heap-checking macros 214, 265–76 invariance macros 257–8, 270–6 just-in-time debugging 248–9 macros xvii, 83–4, 255–64, 265–76 panics 247–9 default constructors 4, 51–2 Delete 5, 9 10, 18, 30–1, 41–4, 53, 95–7, 172–215 DeleteAll 105 DeleteL 106 –8 DeleteTask 95 109 deletions checklist 335 D suffixes xvii Des 62–4, 66–8, 82–4, 310 12 descriptors 3, 12, 55–73, 75–90, 103 –4, 192–215, 321–5, 337–8... changes 286 DoRecognizeL 219 DoRollBack 45–6 DoSetupAndCombineL 328 DoSomething 284 DoTaskStep 144–8 DServer 175–215 DSession 171, 175–215 DThread 176–215 Duplicate 154–66 dynamic arrays 91 109 , 220–4, 293–7 CArrayX 91 109 , 321 concepts 91 109 , 293–7 definition 91–2 descriptors 103 –4 examples 95 109 granularity considerations 91–2, 106 –8, 321 RArray 91–2, 97 109 , 197–8, 293–7, 321 dynamic buffers INDEX... schedules threads for execution 10 L function A function with a trailing L in its name, e.g NewL(), which indicates that it may leave 2 leave Symbian OS exception handling A function leaves when User::Leave()is called It causes a return to the current trap harness 2 mixin An interface class for ”mixing in” with primary base classes, and the only form of multiple inheritance encouraged on Symbian OS 1 module... conventions xv CArrayFixBase 103 –4 CArrayFixFlat 92–3, 103 –4 CArrayFixSeg 92, 103 CArrayPakFlat 93 CArrayPtrFlat 93 CArrayPtrSeg 94–6, 98–9, 100 –9 CArrayVar 94–6 CArrayVarBase 94–6 CArrayVarFlat 93–6 CArrayVarSeg 92, 93–6 CArrayX 91 109 , 321 see also dynamic arrays concepts 91 109 , 321 inheritance class hierarchies 94 naming scheme 92–3 performance overheads 92, 321 RArray contrasts 102 –3 suffixes 92–6 casts,... (1996) Inside the C++ Object Model Publisher: Addison Wesley ISBN: 0201834545 Scott Meyers (1997) Effective C++: 50 Specific Ways to Improve Your Programs and Designs, 2nd Edition Publisher: Addison Wesley ISBN: 0201924889 Scott Meyers (1996) More Effective C++: 35 New Ways to Improve Your Programs and Designs Publisher: Addison Wesley ISBN: 020163371X Bjarne Stroustrup (2000) The C++ Programming Language,... CAsyncTask 158–61 catch ,C++ 13, 15 CBase class cleanup stack 34–44, 50–3 concepts 4–5, 8–11, 30, 34–41, 50–3, 60, 92 109 , 115, 133, 139, 144, 154, 176, 193, 221, 236–7, 250–1, 269, 282–3, 290, 314–15, 322–4 copy constructors 4–6, 314–15 instantiating example 30 virtual destructors 9 10 zero initialization 5, 53, 103 , 322 CBufBase 94–6, 102 –9 CBufFlat 94–6, 106 –8 CBufSeg 94–6, 106 –8 CCleanup 37–8 CCleanupStack::PushL, . Resources Books on Symbian OS Richard Harrison (2003) Symbian OS C++ for Mobile Phones Publisher: John Wiley and Sons Ltd ISBN: 0470856114 Richard Harrison (2004) Symbian OS C++ for Mobile Phones. exported items. On Symbian OS, these items are indexed by ordinal. 13 E32 Collective term for the base components of Symbian OS. ECOM A generic framework in Symbian OS from v7.0 for use with plug-in. (1999) Exceptional C++ Publisher: Addison Wesley ISBN: 0201615622 Symbian OS on the Internet Symbian Press Website www .symbian. com/books Symbian Developer Network www .symbian. com/developer Symbian Developer