|
|
|
|
@ -9,34 +9,34 @@
|
|
|
|
|
#include "../core/mem_func.hpp"
|
|
|
|
|
|
|
|
|
|
/** Base class for simple binary blobs.
|
|
|
|
|
* Item is byte.
|
|
|
|
|
* The word 'simple' means:
|
|
|
|
|
* - no configurable allocator type (always made from heap)
|
|
|
|
|
* - no smart deallocation - deallocation must be called from the same
|
|
|
|
|
* module (DLL) where the blob was allocated
|
|
|
|
|
* - no configurable allocation policy (how big blocks should be allocated)
|
|
|
|
|
* - no extra ownership policy (i.e. 'copy on write') when blob is copied
|
|
|
|
|
* - no thread synchronization at all
|
|
|
|
|
*
|
|
|
|
|
* Internal member layout:
|
|
|
|
|
* 1. The only class member is pointer to the first item (see union ptr_u).
|
|
|
|
|
* 2. Allocated block contains the blob header (see CHdr) followed by the raw byte data.
|
|
|
|
|
* Always, when it allocates memory the allocated size is:
|
|
|
|
|
* sizeof(CHdr) + <data capacity>
|
|
|
|
|
* 3. Two 'virtual' members (m_size and m_max_size) are stored in the CHdr at beginning
|
|
|
|
|
* of the alloated block.
|
|
|
|
|
* 4. The pointter (in ptr_u) pobsize_ts behind the header (to the first data byte).
|
|
|
|
|
* When memory block is allocated, the sizeof(CHdr) it added to it.
|
|
|
|
|
* 5. Benefits of this layout:
|
|
|
|
|
* - items are accessed in the simplest possible way - just dereferencing the pointer,
|
|
|
|
|
* which is good for performance (assuming that data are accessed most often).
|
|
|
|
|
* - sizeof(blob) is the same as the size of any other pointer
|
|
|
|
|
* 6. Drawbacks of this layout:
|
|
|
|
|
* - the fact, that pointer to the alocated block is adjusted by sizeof(CHdr) before
|
|
|
|
|
* it is stored can lead to several confusions:
|
|
|
|
|
* - it is not common pattern so the implementation code is bit harder to read
|
|
|
|
|
* - valgrind can generate warning that allocated block is lost (not accessible)
|
|
|
|
|
* */
|
|
|
|
|
* Item is byte.
|
|
|
|
|
* The word 'simple' means:
|
|
|
|
|
* - no configurable allocator type (always made from heap)
|
|
|
|
|
* - no smart deallocation - deallocation must be called from the same
|
|
|
|
|
* module (DLL) where the blob was allocated
|
|
|
|
|
* - no configurable allocation policy (how big blocks should be allocated)
|
|
|
|
|
* - no extra ownership policy (i.e. 'copy on write') when blob is copied
|
|
|
|
|
* - no thread synchronization at all
|
|
|
|
|
*
|
|
|
|
|
* Internal member layout:
|
|
|
|
|
* 1. The only class member is pointer to the first item (see union ptr_u).
|
|
|
|
|
* 2. Allocated block contains the blob header (see CHdr) followed by the raw byte data.
|
|
|
|
|
* Always, when it allocates memory the allocated size is:
|
|
|
|
|
* sizeof(CHdr) + <data capacity>
|
|
|
|
|
* 3. Two 'virtual' members (m_size and m_max_size) are stored in the CHdr at beginning
|
|
|
|
|
* of the alloated block.
|
|
|
|
|
* 4. The pointter (in ptr_u) pobsize_ts behind the header (to the first data byte).
|
|
|
|
|
* When memory block is allocated, the sizeof(CHdr) it added to it.
|
|
|
|
|
* 5. Benefits of this layout:
|
|
|
|
|
* - items are accessed in the simplest possible way - just dereferencing the pointer,
|
|
|
|
|
* which is good for performance (assuming that data are accessed most often).
|
|
|
|
|
* - sizeof(blob) is the same as the size of any other pointer
|
|
|
|
|
* 6. Drawbacks of this layout:
|
|
|
|
|
* - the fact, that pointer to the alocated block is adjusted by sizeof(CHdr) before
|
|
|
|
|
* it is stored can lead to several confusions:
|
|
|
|
|
* - it is not common pattern so the implementation code is bit harder to read
|
|
|
|
|
* - valgrind can generate warning that allocated block is lost (not accessible)
|
|
|
|
|
*/
|
|
|
|
|
class CBlobBaseSimple {
|
|
|
|
|
public:
|
|
|
|
|
typedef ::ptrdiff_t bsize_t;
|
|
|
|
|
@ -312,12 +312,12 @@ public:
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/** Blob - simple dynamic Titem_ array. Titem_ (template argument) is a placeholder for any type.
|
|
|
|
|
* Titem_ can be any integral type, pointer, or structure. Using Blob instead of just plain C array
|
|
|
|
|
* simplifies the resource management in several ways:
|
|
|
|
|
* 1. When adding new item(s) it automatically grows capacity if needed.
|
|
|
|
|
* 2. When variable of type Blob comes out of scope it automatically frees the data buffer.
|
|
|
|
|
* 3. Takes care about the actual data size (number of used items).
|
|
|
|
|
* 4. Dynamically constructs only used items (as opposite of static array which constructs all items) */
|
|
|
|
|
* Titem_ can be any integral type, pointer, or structure. Using Blob instead of just plain C array
|
|
|
|
|
* simplifies the resource management in several ways:
|
|
|
|
|
* 1. When adding new item(s) it automatically grows capacity if needed.
|
|
|
|
|
* 2. When variable of type Blob comes out of scope it automatically frees the data buffer.
|
|
|
|
|
* 3. Takes care about the actual data size (number of used items).
|
|
|
|
|
* 4. Dynamically constructs only used items (as opposite of static array which constructs all items) */
|
|
|
|
|
template <class Titem_, class Tbase_ = CBlobBaseSimple>
|
|
|
|
|
class CBlobT : public Tbase_ {
|
|
|
|
|
// make template arguments public:
|
|
|
|
|
|
rubidium
15 years ago