Modules | |
Win32 Synchronization primitives | |
Win32 Threading primitives | |
Win32 I/O Completion Ports | |
Timer management | |
Opaque user data | |
Opaque user data is the name given to the concept of storing an arbitrary number of void * pieces of 'user data' in a class. The user of the class knows what the data is, the class itself doesn't care and, to it, the data is opaque. Generally the class that supports user data inherits from IIndexedOpaqueUserData and when it's created it has x 'slots' of user data created with it. Users of the class can then store their own things in the class. Classes that allocate objects that support user data generally inherit from IProvideUserData which allows the users to request a user data 'slot' and get given an index to it. Generally users request their slots before the first object that supports user data from this allocator is allocated (so all objects have the same number of slots!). Indices are allocated by name (and this is often the name of the class doing the requesting) so that there's no need for a central repository of information relating to how many user data slots each object needs to support. An example of this code in action can be seen in the IO Tools library with the IBufferAllocator and IBuffer interfaces and the Socket Tools library with the ISocketAllocator and various socket classes. The extensible nature of this design means that it's easy for code to be layered on top of the existing code that uses (and requires) user data in the sockets or buffers and for it to require as much or as little user data as it likes. The intefaces for this should probably be moved to the C++ Tools library as there's no dependency on Win32. | |
Security | |
Interprocess Communication | |
Classes | |
class | CSimpleFixedSizedMemoryAllocator |
A class that provides naive fixed sized memory allocation. Note that once the allocator has requested memory from the operating system it never returns it to the operating system, it simply keeps it around until another allocation request can use it. So, if you allocate 1000 1024 byte blocks and then free them all the allocator itself is still holding on to 1024000 bytes of memory. The allocator uses VirtualAlloc() to allocate the memory that it uses, this allows it to provide page aligned memory if requested to do so. It also means that internally it works in terms of multiples of the system's allocation granularity when allocating chunks of memory that it can slice up into blocks to return to the caller. Also, if you specify that you want page alignment and the memory block size that you're using is smaller than an exact page multiple then the difference between the block size and the next multiple of the page size will be 'wasted'. More... |