Memory leaks reported on different calls to DBTools.h++ or Tools.h++ methods.

The libraries use static allocations, including a form of memory caching, which some unsophisticated utilities may report as a memory leak. These are NOT memory leaks. A memory leak typically occurs when newed memory is not deleted, resulting in a continual loss of available heap space. The memory used by the DBTools.h++ static allocations is very limited (typically less than 200 bytes), is allocated only once, and is returned to the operating system when the application terminates.

If the user requires a complete and accurate assessment of memory usage, we recommend a professional product such as Purify. Commonly available utilities may give incomplete, misleading, or incorrect results.

There are three common sources for these types of reports: system-specific information such as RWZone and RWLocale, the RWFactory object, and a memory cache used by most of our collections called RWMemoryPool.

Information about a system's time zone and locale is very expensive to calculate. Because of this, we do not calculate this information until the first time the program tries to use it, and then we keep a pointer to this information so we don't have to recalculate it. This saved information may show up as a memory leak.

The RWFactory object is used to keep track of all the RWCollectable objects used within a program. This is accomplished by having a static initialize for each RWCollectable insert an entry into the RWFactory. Because the RWFactory is a global object that could be accessed at any time we can not remove it from memory until the program terminates. Some memory checkers may record the RWFactory and each of the entries inserted into it (one for each RWCollectable class used by the program) as a leak.

The RWMemoryPool is a way of increasing the speed of collections that allocate and deallocate lots of small objects, such as the individual nodes of a linked list. It accomplishes this by keeping a small number of allocations of a known size and reusing them rather than returning them to the operating system. By default, the number of allocations cached is 5 each of sizes 2,4,6,8, and 10 bytes. Using these numbers, the most that will be cached is 150 bytes in 25 allocations. Most programs will use much less.

The RWMemoryPool caching can be turned off using the method below. This method will have performance penalties and will not eliminate the other types of allocations.

To turn caching off, change the following line in mempool.h (near the end of the file) from:

 #ifdef RW_MULTI_THREAD 

to:

 #if defined(RW_MULTI_THREAD) || defined(RW_NO_CACHE) 

Then rebuild the DBTools.h++ and the corresponding Tools.h++ libraries, and your application, all with RW_NO_CACHE defined.

Also Roguewave uses Purify as a utility tool
to check the memory leak as most of other utilities
doesn't understand RW's reference counting mechanism