diff -r 4816d766a08a -r f345bda72bc4 Symbian3/PDK/Source/GUID-539C4AA4-FF3F-4D6B-90A5-677092DBE54E.dita --- a/Symbian3/PDK/Source/GUID-539C4AA4-FF3F-4D6B-90A5-677092DBE54E.dita Tue Mar 30 11:42:04 2010 +0100 +++ b/Symbian3/PDK/Source/GUID-539C4AA4-FF3F-4D6B-90A5-677092DBE54E.dita Tue Mar 30 11:56:28 2010 +0100 @@ -1,56 +1,56 @@ - - - - - -Exporting -Global Data from a DLLExporting global data from a DLL to be accessed by either P.I.P.S. -or Symbian C++ applications is one of the typical problems that developers -encounter. -

It is strongly recommended to avoid having global data in DLLs due to following -reasons:

- -

On having understood the above limitations, the following pattern can be -used for exporting global data from a DLL:

-
    -

  1. Do not export global -variables. Within DLL, say there is one global variable, for example:

    int globalVal;
    2. -

  2. Export one method that -returns a pointer to that variable.

    extern "C" EXPORT_C int* GlbData () - { - return &globalVal - } -
    3. -

  3. Define a macro for the -user of the DLL. Within the DLL header (for example, xxx.h), -define the following:

    #ifdef __cplusplus -extern "C" -#endif -IMPORT_C int* GlbData (); -#define globalVal (*GlbData())

    And the usage is like:

    #include <xxx.h> // DLL header -int main() - { - int i = 0; - globalVal = 10; - globalVal++; - i = globalVal; - return 0; - } -
    4. -
+ + + + + +Exporting +Global Data from a DLLExporting global data from a DLL to be accessed by either P.I.P.S. +or Symbian C++ applications is one of the typical problems that developers +encounter. +

It is strongly recommended to avoid having global data in DLLs due to following +reasons:

+
    +

  • EKA2 emulator allows only a DLL with WSD to load into a single process.

    • +

  • RAM usage for WSD data chunk is atleast one 4K RAM page (the smallest +possible RAM allocation), irrespective of how much static data is required.

    • +

  • Chunks are a finite resource on ARMv5. Every process loading WSD enabled +DLLs uses a chunk to hold the data.

    • +

  • There are ARM architecture 4 and 5 specific costs and limitations that +apply only to DLLs that link against “fixed processes”.

    • +

  • There is a limit on the number of DLLs in a process with WSD.

    • +
+

On having understood the above limitations, the following pattern can be +used for exporting global data from a DLL:

+
    +

  1. Do not export global +variables. Within DLL, say there is one global variable, for example:

    int globalVal;
    2. +

  2. Export one method that +returns a pointer to that variable.

    extern "C" EXPORT_C int* GlbData () + { + return &globalVal + } +
    3. +

  3. Define a macro for the +user of the DLL. Within the DLL header (for example, xxx.h), +define the following:

    #ifdef __cplusplus +extern "C" +#endif +IMPORT_C int* GlbData (); +#define globalVal (*GlbData())

    And the usage is like:

    #include <xxx.h> // DLL header +int main() + { + int i = 0; + globalVal = 10; + globalVal++; + i = globalVal; + return 0; + } +
    4. +
 \ No newline at end of file