Small Memory Allocation, Page 3
- Allocators usually follow the FIXED ALLOCATION idiom—being allocated at the very beginning and released at the very end of the program. They are usually singletons, meaning that the same instance is accessible all the time via a static call—there is no need to keep a reference of that particular instance. Unfortunately, this is not true in BREW because no static data is allowed. A clean solution is to keep the class instantiated directly by BREW (CPPApp (86 Kb) in our examples) as a context, used mainly as a placeholder for different handlers and managers. Please note that this is not a real C++ class, but a POD structure because BREW doesn't have direct knowledge of any of C++ artifacts, so using it as a repository is natural.
- Using C++ constructs in C ("a better C") or simply using some helper C++ classes such asas "libraries" definitely confers more robustness and clarity to the code. For example, allocators described here can be used from C.
The main topic of this article was memory allocation and how to avoid fragmentation problems. The next installment will discuss another interesting subject—memory exhaustion. We will present some useful idioms automating deallocation together with other helpful ways of avoiding fragmentation.
 James Noble, Charles Weirr: Small Memory software - Patterns for systems with limited memory. Addison Wesley, 2001
 Bjarne Stroustrup: The C++ Programming Language. Addison-Wesley, 2000
 For Brew Developers, There Are New Kids in Town: IThread & IRscPool http://www.developer.com/ws/brew/article.php/3085401
 Andrei Alexandrescu: Modern C++ Design. Addison Wesley, 2001
Page 3 of 3