Application Memory Allocation

< BACK  NEXT >

[oR]

Applications can allocate memory for variables in one of three ways:

• Global, or static memory allocation

• Heap-based allocation

• Stack-based allocation

These three techniques allocate variables with different scope and lifetime. The variable's scope determines which part of an application can use the variable. The lifetime determines when the variable is created, and for how long. The following sections describe the three allocation techniques, the lifetime and scope of the variables, and the uses and abuses of each.

Global and Static Memory Allocation

Global variables are declared outside of functions, and static variables are declared inside functions with the "static" modifier:

 int g_nVar;    // global variable void f() {   static int n;  // static variable } 

Global and static variables are created when the process starts running and are destroyed when the process terminates. The lifetime of such variables is the same as the process's lifetime. Therefore, they occupy memory for the entire time the process is running. You should avoid using global and static variables in Windows CE applications, as the program cannot free the memory occupied by such variables. This is especially true for global or static arrays.

A static variable's scope is the function in which it is declared. Thus, only code in the function after the static variable's declaration can access the variable. Global variables are accessible by any code in a source file that comes after the global variable's declaration, or in other source files if the source files declare the variable using the extern modifier.

Heap-Based Allocation

When a process is started Windows CE creates a default heap for the process. Memory can be allocated from this heap using a variety of different functions and techniques, including the following:

• The C run-time function alloc

• The C++ new operator

• The API functions LocalAlloc or HeapAlloc

Each of these techniques allows an allocation of a specified size to be made, and a pointer to the memory is returned. The memory can then be accessed through the pointer. Using a heap simplifies memory management, since you don't need to be concerned about the page allocation and de-allocation.

The heap is initially created with 384 KB of address space reserved for the heap, but without any actual physical memory associated with the heap. As memory allocations are made, physical memory is allocated to these pages. If the size of the heap exceeds 384 KB, more address space is allocated to the heap. Note that the heap may not be in contiguous memory.

Memory can be freed using one of these techniques:

• The C run-time function free

• The C++ delete operator

• The API functions LocalFree or HeapFree

The following code shows a typical allocation using LocalAlloc and LocalFree.

 LPTSTR lpStr; lpStr = (LPTSTR)LocalAlloc(LPTR, 100 * sizeof(TCHAR)); if(lpStr == NULL) {   // out of memory } else {   // use the pointer lpStr...   LocalFree(lpStr); } 

The code allocates memory for 100 TCHAR characters, which under Windows CE using Unicode will result in a memory allocation of 200 bytes. The LPTR constant specifies that LocalAlloc will return a pointer and that the memory block will be filled with NULL bytes.

The space occupied by the freed block is then available to another allocation. Over time, the heap can become fragmented, so more memory and address space is used than is actually required for allocations currently in use. This is one of the major downsides to using a heap, especially for applications that may be running over a long period of time. One solution to this problem is to create additional heaps for specific allocation purposes. These heaps can be deleted to free all the memory occupied by the heap. This technique is described later in this chapter. Note that the default heap cannot be deleted.

The scope and lifetime of data allocated from the heap is totally in the control of the application. The pointer returned from an allocation can be passed to any function, allowing the data to be accessed by those functions. However, it is generally best to limit the access to the pointer, and hence the scope, by encapsulating the pointer. This involves providing functions or a C++ class that controls access to the pointer. An application can decide when to allocate and free the memory, and therefore has control over the scope.

In general, the heap is the best place to allocate memory for variables that need a variable lifetime and must be accessed by several different functions.

Stack-Based Allocation

When a process is created, Windows CE creates a stack for the primary thread. The stack is used to store information about each function call, including any parameters passed to the function, any local variables declared in the function, and the address to where the function should return. All the information about a function call is stored in a "stack frame." A stack in Windows CE can be up to 60 KB, and initially a single page is allocated for the stack. Of the 60 KB, 58KB can be used for the stack and the remaining 2 KB is used to detect stack overflows.

Any variable declared in a function, or parameter passed to a function, will use the stack for storage. When the function returns, the variables and parameters will be destroyed. The scope of variables and parameters is always the function in which they are declared. The lifetime of the variables and parameters is from the time the function is called to the time the function returns.

Each new thread created in a process must have its own stack, and Windows CE creates this automatically. Any functions called in a DLL will use the stack owned by the thread that is used to call the function.

In general, you should be careful not to declare local variables of excessive size remember that the amount of stack used is the size of all the local variables and parameters for all function calls in the call list. Your application will fail if this exceeds 58 KB.

< BACK  NEXT >