#include <Buffer.h>

Inheritance diagram for MBase::Buffer:

Public Types
enum	BlockSizes { MIN_BLOCK_SIZE = 256, NT_BLOCK_SIZE = 4096 }

Public Member Functions
virtual void	Delete ()=0 throw ()

virtual bool	Reserve (size_t iSize)=0

virtual void *	GetMem (size_t iSize)=0

virtual unsigned Int32	GetTotalMemSize () const =0

virtual unsigned Int32	GetAllocMemSize () const =0

virtual unsigned Int64	GetTotalMemSizeInBytes () const =0

virtual unsigned Int64	GetAllocMemSizeInBytes () const =0

virtual void	WriteLock ()=0

virtual void	SetTotalAllocatedSpaceLimit (Int64 iLimit)=0

virtual	~Buffer () throw ()

Detailed Description

Buffer is supposed to make performance better by allocating medium chunks (1 page) of contiguous memory, and giving it out to the client object as it requests it (in theory the client object will request for smaller chunks). Given that the OS provides good allocators (and we use SmartHeap that provides an even better one), this performance gain is not really true. Buffer is also supposed to reduce fragmentation, by keeping memory that has similar lifespan in one contiguous block. However, given that again, OS and SmartHeap allocators use memory pools, fragmentation is not really reduced significantly by buffer. Finally, Buffer was thought of a way of reducing memory leaks. The idea is that you can allocate something in the buffer and it will magically get deleted. However, though memory gets deleted, destructors of the allocated objects are not called, which violates a principle of C++ (where you are supposed to be able to rely on destructors getting called). Furthermore, though leaks do not originate from Buffer, it has severe unnecessary memory usage. On avergae, half a page will be wasted per buffer. Furthermore, objects that may have gone out of scope early on, will continue to linger and use up memory until the Buffer gets destroyed.

In short, DO NOT USE Buffer. :) We only keep it here to support the current code base, and hope that sometime we will be able to retire it.