FSBAllocator: FSB: Fixed-Size Block Allocator suite for C++. This is a more generic fixed-size block allocator, which is very suitable for use with the C++ STL data containers which allocate one element at a time, ie. std::list, std::set and std::map. It cannot be used with std::vector, std::deque nor std::string (but on the other hand the memory usage of those containers is already very good, so they don’t really need a specialized allocator). The allocator works by allocating contiguous blocks of memory where the allocated elements are stored. The size of the element is determined automatically from the objects to be allocated. Basically an allocator is created for every element size that is used. (On the other hand, if two different data containers use elements of the same size, they will share the same allocator.) If an entire block of elements is deallocated, then the block will be freed from the main memory as well. Besides the obvious advantage of memory being freed for other uses, this has also speed advantages (because if the block is allocated again, it will be cache-friendly and consecuently very fast). Each allocated element has an overhead of 4 bytes in 32-bit systems (8 bytes in 64-bit systems), which is the same as with most default memory allocators. Thus this allocator does not consume any more memory than the default one. In fact, it can sometimes allocate even less memory than the default allocator because many such allocators align allocated elements to 8-byte boundaries, while FSBAllocator allocates to 4-byte boundaries (in 32-bit systems). The disadvantages of using this allocator are the following: The memory used by this allocator cannot be shared with anything else in the program which uses dynamically allocated memory. This allocator supports allocating only individual elements. It cannot be used to allocate arrays (which is why it cannot be used with std::vector nor std::deque). On the other hand, this is usually not a problem. If the memory allocated using this allocator becomes fragmented, it may in some cases cause the allocator to waste considerable amounts of memory. (This happens mainly if a lot of elements are allocated and then the majority of them are deallocated, but random individual elements here and there aren’t.) This allocator is not thread-safe by default. However, the library offers several possibilities for making it thread-safe with a precompiler constant. See the thread-safety section below.

Keywords for this software

Anything in here will be replaced on browsers that support the canvas element

References in zbMATH (referenced in 1 article )

Showing result 1 of 1.
Sorted by year (citations)

  1. Alfonso Niño, Camelia Muñoz-Caro, Sebastián Reyes: APINetworks: A general API for the treatment of complex networks in arbitrary computational environments (2015) not zbMATH