tango.util.container.Container

License:
BSD style:

Version:
Apr 2008: Initial release Jan 2009: Added GCChunk allocator

Authors:
Kris, schveiguy

Since:
0.99.7

struct Container;
Utility functions and constants

size_t defaultInitialBuckets;
default initial number of buckets of a non-empty hashmap

float defaultLoadFactor;
default load factor for a non-empty hashmap. The hash table is resized when the proportion of elements per buckets exceeds this limit

void reap(V)(V v);
generic value reaper, which does nothing

void reap(K, V)(K k, V v);
generic key/value reaper, which does nothing

size_t hash(K)(K k, size_t length);
generic hash function, using the default hashing. Thanks to 'mwarning' for the optimization suggestion

struct ChunkGC(T);
GC Chunk allocator

Can save approximately 30% memory for small elements (tested with integer elements and a chunk size of 1000), and is at least twice as fast at adding elements when compared to the generic allocator (approximately 50x faster with LinkedList)

Operates safely with GC managed entities

T* allocate();
allocate a T-sized memory chunk

T*[] allocate(size_t count);
allocate an array of T* sized memory chunks

void collect(T*[] t);
Invoked when a specific T*[] is discarded

void collect(T* p);
Invoked when a specific T is discarded

bool collect(bool all = true);
Invoked when clear/reset is called on the host. This is a shortcut to clear everything allocated.

Should return true if supported, or false otherwise. False return will cause a series of discrete collect calls

void config(size_t chunks, size_t allocate = 0);
set the chunk size and prepopulate with nodes

void newlist();
list manager

struct Chunk(T);
Chunk allocator (non GC)

Can save approximately 30% memory for small elements (tested with integer elements and a chunk size of 1000), and is at least twice as fast at adding elements when compared to the default allocator (approximately 50x faster with LinkedList)

Note that, due to GC behaviour, you should not configure a custom allocator for containers holding anything managed by the GC. For example, you cannot use a MallocAllocator to manage a container of classes or strings where those were allocated by the GC. Once something is owned by a GC then it's lifetime must be managed by GC-managed entities (otherwise the GC may think there are no live references and prematurely collect container contents).

You can explicity manage the collection of keys and values yourself by providing a reaper delegate. For example, if you use a MallocAllocator to manage key/value pairs which are themselves allocated via malloc, then you should also provide a reaper delegate to collect those as required.

The primary benefit of this allocator is to avoid the GC scanning the date-structures involved. Use ChunkGC where that option is unwarranted, or if you have GC-managed data instead

T* allocate();
allocate a T-sized memory chunk

T*[] allocate(size_t count);
allocate an array of T* sized memory chunks

void collect(T*[] t);
Invoked when a specific T*[] is discarded

void collect(T* p);
Invoked when a specific T is discarded

bool collect(bool all = true);
Invoked when clear/reset is called on the host. This is a shortcut to clear everything allocated.

Should return true if supported, or false otherwise. False return will cause a series of discrete collect calls

void config(size_t chunks, int allocate = 0);
set the chunk size and prepopulate with nodes

void newlist();
list manager

struct Collect(T);
generic GC allocation manager

Slow and expensive in memory costs

T* allocate();
allocate a T sized memory chunk

T*[] allocate(size_t count);
allocate an array of T sized memory chunks

void collect(T* p);
Invoked when a specific T[] is discarded

void collect(T*[] t);
Invoked when a specific T[] is discarded

bool collect(bool all = true);
Invoked when clear/reset is called on the host. This is a shortcut to clear everything allocated.

Should return true if supported, or false otherwise. False return will cause a series of discrete collect calls

void config(size_t chunks, int allocate = 0);
set the chunk size and prepopulate with nodes

struct Malloc(T);
Malloc allocation manager.

Note that, due to GC behaviour, you should not configure a custom allocator for containers holding anything managed by the GC. For example, you cannot use a MallocAllocator to manage a container of classes or strings where those were allocated by the GC. Once something is owned by a GC then it's lifetime must be managed by GC-managed entities (otherwise the GC may think there are no live references and prematurely collect container contents).

You can explicity manage the collection of keys and values yourself by providing a reaper delegate. For example, if you use a MallocAllocator to manage key/value pairs which are themselves allocated via malloc, then you should also provide a reaper delegate to collect those as required.

T* allocate();
allocate an array of T sized memory chunks

T*[] allocate(size_t count);
allocate an array of T sized memory chunks

void collect(T*[] t);
Invoked when a specific T[] is discarded

void collect(T* p);
Invoked when a specific T[] is discarded

bool collect(bool all = true);
Invoked when clear/reset is called on the host. This is a shortcut to clear everything allocated.

Should return true if supported, or false otherwise. False return will cause a series of discrete collect calls

void config(size_t chunks, int allocate = 0);
set the chunk size and prepopulate with nodes


Page generated by Ddoc. Copyright (c) 2008 Kris Bell. All rights reserved