|
MiscellaneousThis page documents library components that don't really fit in anywhere else. They all basically follow the same conventions as the rest of the library. So to get a pipe for example you would need to write something like typedef dlib::pipe::kernel_1a pipe_type; and from then on make your pipes like pipe_type my_pipe(pipe_size);. |
|
bit_stream_kernel_1:
This implementation is done by buffering single bits in the obvious way.
kernel_1ais a typedef for bit_stream_kernel_1 kernel_1a_cis a typedef for kernel_1a that checks its preconditions.
bit_stream_multi_1:
This implementation is done by calling the read/write functions in the bit_stream kernel.
multi_1ais a typedef for bit_stream_kernel_1 extended by bit_stream_multi_1 multi_1a_cis a typedef for multi_1a that checks its preconditions.
bound_function_pointer_kernel_1:
This implementation is done using type erasure and placement new. This means that it never allocates memory on the heap and instead stores everything on the stack.
kernel_1ais a typedef for bound_function_pointer_kernel_1 kernel_1a_cis a typedef for kernel_1a that checks its preconditions.
byte_orderer_kernel_1:
This implementation is done in the obvious way.
kernel_1ais a typedef for byte_orderer_kernel_1
This library comes with a command line driven regression test suite. All the testing code is located in the dlib/test folder. If you want to build it and test the library on your system you can use the makefile at dlib/test/makefile (you may have to edit it to make it work on your system) or use the CMake CMakeLists.txt file at dlib/test/CMakeLists.txt to build it.
What you may find more useful however is the testing framework itself. It uses a fairly simple and modular design. Each test is contained in its own cpp file and when compiled into the program it automatically shows up in the list of tests to run. If you want to use the testing framework all you need to do is add the files dlib/test/tester.h, dlib/test/tester.cpp, and dlib/test/main.cpp to your project and then add cpp files that contain your tests (see dlib/test/example.cpp and dlib/test/example_args.cpp for some examples).
From the command line you can choose to run all the installed tests, enable or disable the loggers, set various logging levels, specify how many times to run the tests, or pick just one or two tests to run at a time rather than the entire suite. The output of the program, that is, its return value from main() is the number of failed tests. So if every test succeeds then it returns 0.
member_function_pointer_kernel_1:
This implementation is done using type erasure and placement new. This means that it never allocates memory on the heap and instead stores everything on the stack.
kernel_1ais a typedef for member_function_pointer_kernel_1 kernel_1a_cis a typedef for kernel_1a that checks its preconditions.
memory_manager_kernel_1:
This memory manager implementation allocates objects one at a time when there are allocation requests. Then when there is a deallocate request the returning object is placed into a list of free blocks if that list has less than max_pool_size blocks in it. Subsequent allocation requests will be serviced by drawing from the free list whenever it isn't empty. Array allocations, on the other hand, are not managed at all but are passed directly on to new and delete.When this object's max_pool_size template parameter is set to 0 it simply calls new and delete directly and doesn't function as a memory pool.
kernel_1ais a typedef for memory_manager_kernel_1 with a max_pool_size of 0 kernel_1bis a typedef for memory_manager_kernel_1 with a max_pool_size of 10 kernel_1cis a typedef for memory_manager_kernel_1 with a max_pool_size of 100 kernel_1dis a typedef for memory_manager_kernel_1 with a max_pool_size of 1000 kernel_1eis a typedef for memory_manager_kernel_1 with a max_pool_size of 10000 kernel_1fis a typedef for memory_manager_kernel_1 with a max_pool_size of 100000
memory_manager_kernel_2:
This memory manager implementation allocates memory in blocks of chunk_size*sizeof(T) bytes. All the sizeof(T) sub-blocks are kept in a linked list of free memory blocks and are given out whenever an allocation request occurs. Also, memory is not freed until this object is destructed. Also note that array allocations are not managed at all but are passed directly on to new and delete.
kernel_2ais a typedef for memory_manager_kernel_2 with a chunk_size of 10 kernel_2bis a typedef for memory_manager_kernel_2 with a chunk_size of 100 kernel_2cis a typedef for memory_manager_kernel_2 with a chunk_size of 1000 kernel_2dis a typedef for memory_manager_kernel_2 with a chunk_size of 10000 kernel_2eis a typedef for memory_manager_kernel_2 with a chunk_size of 100000
memory_manager_kernel_3:
This memory manager implementation allocates memory in blocks of chunk_size*sizeof(T) bytes. All the sizeof(T) sub-blocks are kept in a linked list of free memory blocks and are given out whenever an allocation request occurs. Note that array allocations are managed. So this object is just like kernel_2 but it also pools memory from array allocations (chunk_size has no effect with respect to array allocations, each array is allocated one at a time). Also, memory is not freed until this object is destructed.
kernel_3ais a typedef for memory_manager_kernel_3 with a chunk_size of 10 kernel_3bis a typedef for memory_manager_kernel_3 with a chunk_size of 100 kernel_3cis a typedef for memory_manager_kernel_3 with a chunk_size of 1000 kernel_3dis a typedef for memory_manager_kernel_3 with a chunk_size of 10000 kernel_3eis a typedef for memory_manager_kernel_3 with a chunk_size of 100000
memory_manager_global_kernel_1:
This is implemented in the obvious way. See the code for details.
kernel_1ais a typedef for memory_manager_global_kernel_1
memory_manager_stateless_kernel_1:
This implementation just calls new and delete. So it doesn't do anything special.
kernel_1ais a typedef for memory_manager_stateless_kernel_1
memory_manager_stateless_kernel_2:
This implementation uses a global instance of a memory_manager object guarded by a mutex as its implementation.
kernel_2_1ais a typedef for memory_manager_stateless_kernel_2 that uses memory_manager_1a kernel_2_1bis a typedef for memory_manager_stateless_kernel_2 that uses memory_manager_1b kernel_2_1cis a typedef for memory_manager_stateless_kernel_2 that uses memory_manager_1c kernel_2_1dis a typedef for memory_manager_stateless_kernel_2 that uses memory_manager_1d kernel_2_1eis a typedef for memory_manager_stateless_kernel_2 that uses memory_manager_1e kernel_2_1fis a typedef for memory_manager_stateless_kernel_2 that uses memory_manager_1f kernel_2_2ais a typedef for memory_manager_stateless_kernel_2 that uses memory_manager_2a kernel_2_2bis a typedef for memory_manager_stateless_kernel_2 that uses memory_manager_2b kernel_2_2cis a typedef for memory_manager_stateless_kernel_2 that uses memory_manager_2c kernel_2_2dis a typedef for memory_manager_stateless_kernel_2 that uses memory_manager_2d kernel_2_2eis a typedef for memory_manager_stateless_kernel_2 that uses memory_manager_2e kernel_2_3ais a typedef for memory_manager_stateless_kernel_2 that uses memory_manager_3a kernel_2_3bis a typedef for memory_manager_stateless_kernel_2 that uses memory_manager_3b kernel_2_3cis a typedef for memory_manager_stateless_kernel_2 that uses memory_manager_3c kernel_2_3dis a typedef for memory_manager_stateless_kernel_2 that uses memory_manager_3d kernel_2_3eis a typedef for memory_manager_stateless_kernel_2 that uses memory_manager_3e
pipe_kernel_1:
This implementation is done using a circular buffer in the obvious way. See the source for details.
kernel_1ais a typedef for pipe_kernel_1
Thus, using this allocator object you can use any of the dlib memory manager objects with the containers in the STL or with any other object that requires an STL style allocator object.
sync_extension_kernel_1:
This is implemented using a rmutex and rsignaler in the obvious way.
kernel_1ais a typedef for sync_extension_kernel_1
timeout_kernel_1:
This is implemented in the obvious way using virtual functions and templates.
kernel_1ais a typedef for timeout_kernel_1
timer_kernel_1:
This is implemented in the obvious way.
kernel_1ais a typedef for timer_kernel_1
timer_kernel_2:
This implementation has a single master thread that does all the waiting. This master thread creates and dispatches threads to specific timer objects when they need to run their action functions. When a timer object isn't executing its action function then it doesn't have any thread allocated to it at all. So it is much more efficient than timer_kernel_1.
kernel_2ais a typedef for timer_kernel_2