These wrappers provide a portable object oriented interface for networking, multithreading, GUI development, and file browsing. Programs written using them can be compiled under POSIX or MS Windows platforms without changing the code.
dir_nav_kernel_1: MS Windows implementation
dir_nav_kernel_2: POSIX implementation
gui_core_kernel_1: MS Windows implementation
gui_core_kernel_2: X Windows implementation
This component is a collection of various windowing widgets such as buttons, labels, text boxes, and so on. It also includes the drawable interface, drawable_window, and font handling objects. dlib/gui_widgets/widgets_abstract.h defines all of the high level graphical widgets provided by this component that can appear in a drawable_window. To view the specifications for the other members of this component look at dlib/gui_widgets/fonts_abstract.h, dlib/gui_widgets/drawable_abstract.h, and dlib/gui_widgets/base_widgets_abstract.h.
This component isn't actually a wrapper on top of OS APIs. Rather, it is implemented on top of the gui_core component. I put it on this page just because I expect that people would look here when searching for the sort of functionality provided by this component.
You also may want to take note of the timeout object. It provides a mechanism which you can use to add a timeout to a network operation.
sockets_kernel_1: MS Windows implementation
sockets_kernel_2: POSIX implementation
You also probably want to take note of the pipe object. It provides an easy to use typesafe mechanism to send messages between threads.
threads_kernel_1: MS Windows implementation
threads_kernel_2: POSIX implementation
This object represents a fixed size group of threads which you can submit tasks to and then wait for those tasks to be completed. It also provides a future object that provides a container which allows you to safely pass objects into the tasks.The implementation of this extension can be found here. It is implemented such that no memory allocations occur after the thread pool has been constructed so long as the user doesn't call any of the add_task_by_value() routines. The future object also doesn't perform any memory allocations or contain any system resources such as mutex objects.