|
1 /* |
|
2 * Copyright (c) 2007-2009 Nokia Corporation and/or its subsidiary(-ies). |
|
3 * All rights reserved. |
|
4 * This component and the accompanying materials are made available |
|
5 * under the terms of the License "Eclipse Public License v1.0" |
|
6 * which accompanies this distribution, and is available |
|
7 * at the URL "http://www.eclipse.org/legal/epl-v10.html". |
|
8 * |
|
9 * Initial Contributors: |
|
10 * Nokia Corporation - initial contribution. |
|
11 * |
|
12 * Contributors: |
|
13 * |
|
14 * Description: |
|
15 * |
|
16 */ |
|
17 |
|
18 |
|
19 /** |
|
20 @file |
|
21 @publishedPartner |
|
22 @released |
|
23 */ |
|
24 |
|
25 #ifndef __ROMLIT_H__ |
|
26 #define __ROMLIT_H__ |
|
27 #include <e32def.h> |
|
28 #include <u32std.h> |
|
29 /** |
|
30 Special ROM friendly _LIT16 replacement. |
|
31 |
|
32 The existing _LIT16 macro/template successfully creates descriptors |
|
33 which will be put into ROM, but it is IMPOSSIBLE to initialize |
|
34 another "romable" variable with the address of one.... |
|
35 |
|
36 What happens is that the compiler thinks it needs to call the |
|
37 TLitC16 operator& function call (even though it is a cast which |
|
38 will be optimized out of existence) to take the address of the |
|
39 object created by _LIT16. |
|
40 |
|
41 The result is that the DESTINATION variable gets moved from ROM to |
|
42 an initialized data area so that the return value of the TLitC16 |
|
43 operator& function can be written to it at run time. |
|
44 |
|
45 The net result is that your code will not be legal in a target DLL |
|
46 (unless you enable thread initialized data, which is not |
|
47 recommended). |
|
48 |
|
49 A solution is to use this macro/class which creates TRomLitC16 |
|
50 objects which have an identical layout to TPtrC16 objects and can |
|
51 generally be used just like all the other descriptor types. |
|
52 |
|
53 You use the _ROMLIT16 macro to create a TRomLitC16 object, then |
|
54 take its address and store that in a TRomLitC16 ptr. Attempting to |
|
55 store its address into other ptr types will compile but encounter |
|
56 the same problem as trying to use _LIT16. |
|
57 |
|
58 In most cases you can just dereference a TRomLitC16 ptr and pass it |
|
59 to any functions which can handle a _LIT16 (due to the out cast |
|
60 operators). If it doesn't automatically work, apply the function |
|
61 operator to the TRomLitC16 which will return a TDescC16 reference |
|
62 (for example ((*ptrToTRomLitC16)()') which is 100% compatible. |
|
63 */ |
|
64 |
|
65 #ifndef __TText_defined |
|
66 #define __TText_defined |
|
67 #ifdef __GCC32__ |
|
68 typedef wchar_t __TText; |
|
69 #else |
|
70 typedef TUint16 __TText; |
|
71 #endif |
|
72 #endif |
|
73 |
|
74 // All L"" strings are correctly aligned to an even boundary so can be |
|
75 // placed directly into the ptr field of a TPtr object. |
|
76 // |
|
77 // Note that the RVCT assembler listings are confusing because a |
|
78 // standalone ALIGN directive's argument is the requested alignment, |
|
79 // but the ALIGN argument to an AREA directive specifies a power of 2 |
|
80 // for alignment. So the following RVCT generated code ensures |
|
81 // wchar_t strings are 2 byte aligned:- |
|
82 // |
|
83 // "AREA ||.constwstring||, DATA, READONLY, MERGE=2, STRINGS, ALIGN=1" |
|
84 #define _ROMLIT16(name,s) \ |
|
85 const static TRomLitC16 name={((EPtrC<<KShiftDesType16) | (sizeof(L##s)/2-1)), L##s} |
|
86 |
|
87 struct TRomLitC16 |
|
88 { |
|
89 operator const TDesC16 *() const |
|
90 { return reinterpret_cast<const TDesC16*>(this); } |
|
91 operator const TDesC16 &() const |
|
92 { return *(TDesC16 *)this; } |
|
93 const TDesC16& operator()() const |
|
94 { return *(TDesC16 *)this; } |
|
95 operator const __TRefDesC16() const |
|
96 { return *(TDesC16 *)this; } |
|
97 TUint iTypeLength; |
|
98 const __TText *iPtr; |
|
99 }; |
|
100 |
|
101 #endif |