Version 43 (modified by viboes, 8 years ago) (diff)

Adding async and coco

WARNING: The contents of this page could be incomplete and outdated. Please help us to improve this page by modifying it directly or posting on the Boost mailing lists  boost-AT-lists.boost.org or  boost-users-AT-lists.boost.org with the prefix `[LibrariesUnderConstruction].

See Boost Releases documentation for the list of libraries Boost by release. See Boost Review Schedule for Boost ongoing details.

Most of the ongoing libraries are stored on the  SVN Sandbox, the  Boost Vault or on specific sites.


Libraries Under Construction

This page is an index page for libraries under construction.


Boost.Algorithm.Sorting

  • Author(s): Steven Ross
  • Version:
  • State:
  • Last upload: 2009 Jan 13
  • Links:  Bosst Vault
  • Categories: Algorithm
  • Description: The Sorting Algorithm Library provides a generic implementation of high-speed sorting algorithms that outperform those in the C++ standard in both average and worst case performance. These algorithms only work on random access iterators.

These algorithms are hybrids using both radix and comparison-based sorting, specialized to sorting common data types, such as integers, floats, and strings. These algorithms are encoded in a generic fashion and accept functors, enabling them to sort any object that can be processed like these basic data types.

Unlike many radix-based algorithms, the underlying Spreadsort algorithm is designed around worst-case performance, and performs better on chunky data (where it is not widely distributed), so that on real data it can perform substantially better than on random data. Conceptually, Spreadsort can sort any data for which an absolute ordering can be determined.


Boost.AllocPlus


Boost.Asio.eos_portable_archive


asynch

  • Author(s): Edd Dawson
  • Version: 0.2.3
  • State:
  • Last upload: 2 Aug 2007
  • Links:  Web Site  Download
  • Categories: Concurrent Programming
  • Description: async is a C++ library to allow the calling of functions and functors in an asynchronous manner, thereby making it easier to improve the level of concurrency and parallelism in your applications.

Boost.AsynchronousExecutors

  • Author(s): Vicente J. Botet Escribá
  • Version: 0.4
  • State: Quite Stable
  • Last upload: 2009 Fev 08
  • Links:  Boost Vault  Boost Sandbox
  • Categories: Concurrent Programming Containers
  • Description: Asynchronous Executors (AE) and Asynchronous Completion Tokens (ACT) in a generic way (or at least this was my intention). The library can be considered as a front-end for several Asynchronous Execution models making it possible to share common algorithms and making easier to switch from an Asynchronous Executors to another.

Next follows the motivation for the library and how the library can manage with this concepts.

In N1833 - Preliminary Threading Library Proposal for TR2 Kevlin Henney introduce the concept of threader and a function thread that evaluate a function asynchronously and returns a joiner handle. In N2185 - Proposed Text for Parallel Task Execution Peter Dimov introduce a fork function able to evaluate a function asynchronously and returns a future handle. In N2276 - Thread Pools and Futures Anthony William introduce launch_in_thread and launch_in_pool function templates which evaluate a function asynchronously either in a specific thread or a thread pool and returns a unique_future handle. In Boost.ThreadPool? Oliver Kowalke propose a complete implementation of a thread pool with a submit function which evaluate a function asynchronously and returns a task handle.

Behind all these proposal there is a concept of asynchronous executor, fork-launch-like function and the asynchronous completion token handle.

Name executor fork-like ACT
Boost.Thread ?? thread constructor thread
Boost.ThreadPool tp::pool submit tp::task
N2276 thread launch_in_thread unique_future<T>
N2276 thread_pool launch_in_pool unique_future<T>
N2185 ?? fork future<T>
N1833 threader thread joiner<T>

The asynchronous completion token models can follows two interfaces, the thread interface and the unique_future interface. Some asynchronous completion token handles allows to recover the result of the evaluation of the function (futures), other allows to manage the underlying thread of execution (thread) and some both (joiner and tp::task).

It seems natural to make a generic fork function that will evaluate a function asynchronously with respect to the calling thread and returns an ACT handle. The following meta-function associated an ACT handle to a asynchronous executor.

template <typename AE, typename T>
struct asynchronous_completion_token {
    typedef typename AE::template handle<T>::type type;
};    

The result of forking a nullary function by an asynchronous executor is given by the following meta-function:

namespace result_of { 
    template <typename AE,typename F>
    struct fork {
        typedef typename asynchronous_completion_token<AE, typename result_of<F()>::type>::type type;
    };   
}

The default implementation of fork delegates on fork asynchronous executor function.

template< typename AE, typename F > 
result_of::fork<AE, F>::type fork( AE& ae, F fn ) {
    return ae.fork(fn);
}

Forking n-ary functions relies on the nullary version and bind.

template< typename AE, typename F, typename A1, ..., typename An > 
asynchronous_completion_token<AE, typename result_of<F(A1,..., An)>::type >::type 
fork( AE& ae, F fn, A1 a1, ..., An an ) {
    return ae.fork( bind( fn, a1, ..., an ) );
}

Boost.Bitfield

  • Author(s): Emile Cormier
  • Version: 0.3
  • State:
  • Last upload: 2006 Mars 15
  • Links:  Boost Vault
  • Categories: Portability
  • Description:Portable bitfields

Boost.Channel

  • Author(s): Yigong Liu
  • Version: 0.4
  • State: Stable
  • Last upload:Jul 15, 2008
  • Links:  Web Site
  • Categories: Distribution
  • Description: Channel is a C++ framework for distributed message passing and event dispatching, configurable with its components (msg ids,routing algorithms...) as template parameters. As a namespace shared by peer threads, channel supports scope control and filtering.


Boost.Chrono

  • Author(s): Beman Dawes
  • Version:
  • State:
  • Last upload:2008 Nov 26
  • Links:  Boost Sandbox
  • Categories: System
  • Description: The Boost Chrono library provides:
    • The C++0x Standard Library's time utilities, including:
      • Class template duration
      • Class template time_point
      • Clocks:
        • system_clock
        • monotonic_clock
        • high_resolution_clock
    • Class template timer, with typedefs:
      • system_timer
      • monotonic_timer
      • high_resolution_timer
    • Process clocks and timers:
      • process_clock, capturing real, user-CPU, and system-CPU times.
      • process_timer, capturing elapsed real, user-CPU, and system-CPU times.
      • run_timer, convenient reporting of process_timer results.
    • The C++0x Standard Library's compile-time rational arithmetic.

Boost.CLI

  • Author(s): Jean-Daniel Michaud
  • Version:
  • State:
  • Last upload: 2007
  • Links:  Boost Vault
  • Categories: Input/Output
  • Description: .

coco

  • Author(s): Edd Dawson
  • Version: 0.2.0
  • State:
  • Last upload: 23 Feb 2008
  • Links:  Web Site  Download
  • Categories: Concurrent Programming
  • Description: coco is a library that implements the Boost.Thread interface but is written in terms of the operating system’s native cooperative threading mechanism, whether that be Fibers on Windows, or the <ucontext.h> functions on POSIX machines.

This means that multi-threaded programs written using Boost.Thread can now be run in a single thread. This is useful for debugging and testing purposes, where it is necessary to look at algorithmic correctness in isolation from correctness of synchronisation.


Boost.Crypto

  • Author(s): Kasra
  • Version:
  • State: (This is not even at beta stage targeted for suggestions and etc ONLY)
  • Last upload:2009 Jan 20
  • Links:  Boost Vault
  • Categories: DataCommunication
  • Description: A library which provides larger number of secure and cryptographical services to the system.

Boost.ConstantTimeSize

  • Author(s): Vicente J. Botet Escribá
  • Version: 0.1
  • State: Stable
  • Last upload:2008 Oct 14
  • Links:  Boost Vault  Boost Sandbox
  • Categories: Containers
  • Description: Boost.ConstantTimeSize defines a wrapper to the STL container list giving the user the choice for the complexity of the size function: linear time, constant time or quasi-constant.

In future versions the library could include a similar wrapper to slist.


Boost.Coroutines

  • Author(s): Giovanni P. Deretta
  • Version:
  • State:
  • Last upload:2008 Mars 05
  • Links:  Boost Sandbox  Boost Vault
  • Categories: Concurrent Programming
  • Description: The Boost.Coroutine library contains a family of class templates that wrap function objects in coroutines. Coroutines are a generalization of subroutines that can return and be reentered more than once without causing the destruction of automatic objects.

Coroutines are useful whenever it is necessary to keep state across a function call, a job usually reserved to stateful function objects.


Boost.Dataflow

  • Author(s): Stjepan Rajko
  • State: Rewriting ongoing
  • Version:
  • Last upload:
  • Links:  Documentation  Boost Sandbox
  • Categories: DataCommunication
  • Description: Dataflow is a generic library for dataflow programming. Dataflow programs can typically be expressed as a graph in which vertices represent components that process data, and edges represent the flow of data between the components. As such, dataflow programs can be easily reconfigured by changing the components and/or the connections.

Boost.Egg

  • Author(s): Shunsuke Sogame
  • State:
  • Version: 0.91.0
  • Last upload: 30 Mars 2008
  • Links:  Documentation  SVN repository  Boost Vault
  • Categories: Function Objects And Higher-order Programming
  • Description: Egg is a header-only library for building Polymorphic Function Object which can be used with Boost.Lambda. Such a function object is called a Major Function Object. Egg mainly provides three components:
    • Function Builders which build Little Functions into Major Function Objects.
    • Function Adaptors which take Polymorphic Function Objects then return adapted ones.
    • Function Objects which are ports of famous function templates.

Boost.Endian

  • Author(s): Beman Dawes
  • Version:
  • State:
  • Last upload:2008 Nov 26
  • Links:  Boost Sandbox
  • Categories: Portability
  • Description: Provides integer-like byte-holder binary types with explicit control over byte order, value type, size, and alignment. Typedefs provide easy-to-use names for common configurations.

These types provide portable byte-holders for integer data, independent of particular computer architectures. Use cases almost always involve I/O, either via files or network connections. Although portability is the primary motivation, these integer byte-holders may also be used to reduce memory use, file size, or network activity since they provide binary integer sizes not otherwise available.


Boost.Euclid

  • Author(s): Andreas Harnack
  • Version: 0.0.3
  • State:
  • Last upload:2008 Nov 26
  • Links:  Boost Vault
  • Categories: Math And Numerics
  • Description: Euclidean vector class templates providing Orientational analysis on geometrical dimensions.

Boost.Extension

  • Author(s): Jeremy Pack
  • Version:
  • State:
  • Last upload:2008 Nov 26
  • Links:  Blog  Download  Headers Boost Sandbox  Libs Boost Sandbox
  • Categories: Reflective Programming
  • Description: The Boost.Extension library has been developed to ease the development of plugins and similar extensions to software using shared libraries. Classes, functions and data can be made available from shared libraries and loaded by the application.

Boost.Fiber

  • Author(s): Oliver Kowalke
  • Version:
  • State:
  • Last upload:2008 Oct 30
  • Links:  Boost Vault
  • Categories: Concurrent Programming
  • Description: Boost.Fiber implements lightweight threads of execution - so called fibers

Boost.Fsm

  • Author(s): Andrey Semashev
  • State:
  • Version:
  • Last upload:
  • Links:  Boost Vault
  • Categories: Data Structures
  • Description:The Boost.FSM library is an implementation of FSM (stands for Finite State Machine) programming concept.

There are many cases when a developer would like to distinguish behavior of a given object depending on some conditions or its internal state. For example, while developing software to control an charging turnstile a programmer would like to separate states in which the turnstile may persist: an idle state, when the device awaits for another passenger that would like to pass; a processing state, when the passenger have come and put his ticket into the device; and the passing state, when the turnstile lets the passenger pass through. In fact, each state describes a different reaction of the machine at the same events. That's why a passenger may only pass after paying for ticket. Obviously, the turnstile have to be able to change its internal state in order to function properly, this is called state switching or transitions between states (or just transitions for short). This implementation is aimed to ease the creation of such state machines in C++. It supports constructing passive automatons (which means that every action the machine performs is a response to some external event) with finite number of states and finite number of transitions (that is why they are called finite state machines). The main goals of the library are:

  • Simplicity. It should be very simple to create state machines using this library.
  • Performance. The state machine infrastructure should not be very time and memory-consuming in order to be applicable in more use cases.
  • Extensibility. A developer may want to add more states to the existing state machine, for example, the maintenance state for the turnstile mentioned above, and this addition should be relatively safe since it shouldn't interfere with the existing states. The developer should also be able to specify additional transitions and events for the machine with minimum modifications to the existing code.

Boost.GGL


Boost.GIL.IO


Boost.InterThreads

  • Author(s): Vicente J. Botet Escribá
  • Version: 0.4
  • State: Quite Stable
  • Last upload: 2009 Fev 08
  • Links:  Boost Vault  Boost Sandbox
  • Categories: Concurrent Programming
  • Description: Boost.InterThreads extends Boost.Threads adding some features:
    • thread decorator: thread_decorator allows to define setup/cleanup functions which will be called only once by thread: setup before the thread function and cleanup at thread exit.
    • thread_decorator can now decorate a nullary function in addition to a callable function
    • thread specific shared pointer: this is an extension of the thread_specific_ptr providing access to this thread specific context from other threads. As it is shared the stored pointer is a shared_ptr instead of a raw one.
    • thread keep alive mechanism: this mechanism allows to detect threads that do not prove that they are alive by calling to the keep_alive_point regularly. When a thread is declared dead a user provided function is called, which by default will abort the program.
    • thread tuple: defines a thread group where the number of threads is know statically and the threads are created at construction time.
    • set_once: a synchronizer that allows to set a variable only once, notifying to the variable value to whatever is waiting for that.
    • thread_tuple_once: an extension of the boost::thread_tuple which allows to join the thread finishing the first, using for that the set_once synchronizer.
    • thread_group_once: an extension of the boost::thread_group which allows to join the thread finishing the first, using for that the set_once synchronizer.

thread_decorator and thread_specific_shared_ptr are based on the original implementation of threadalert written by Roland Schwarz.

This library works well with AsynchronousExecutors.


Boost.ITL


Boost.Log

  • Author(s): Andrey Semashev ` andrey.semashev__AT__gmail.com
  • Version: RC3
  • State: review version
  • Last upload: 2009 Fev 8
  • Links:  Home Page  Review Version
  • Categories: Input/Output
  • Description: This library aims to make logging significantly easier for the application developer. It provides a wide range of out-of-box tools, along with public interfaces ready to be used to extend the library. The main goals of the library are:
    • Simplicity. A small example code snippet should be enough to get the feel of the library and be ready to use its basic features.
    • Extensibility. A user should be able to extend functionality of the library with regard to collecting and storing information into logs.
    • Performance. The library should make as least performance impact on the user's application as possible.

Boost.LUID

  • Author(s): Vicente J. Botet Escribá
  • Version: 0.0.0
  • State: Prototype
  • Last upload: 2009 Fev 16
  • Categories: Data Structures
  • Links:  Boost Sandbox
  • Description: Boost.LUID simplifies the generation of locally unique identifiers in a wide context.

Locally Unique Identifier or LUID is a special type of identifier used in software applications in order to provide a reference number which is unique in a given context (hence, "Locally" in opposition to "Globally" or "Universally"). Each generated LUID is guaranteed to be unique in its context.

LUID could have many applications. Some examples follow: creating unique identifiers in a database tables, network messages may be identified with a LUID to ensure that this messages are associated to a given session, transactions may be identified by LUIDs.

Note. Please let me know other applications of luids you can have.

  • Reduced identifier size

An attractive feature of LUIDs when compared to alternatives is the minimal size used by this identifiers, that depends on the number of instances a given context can have (usually 4 bytes). This allows to use them in protocols fixing the size of the references exchanged to less that 16 bytes(as it is the case of UUID and GUID). Usually LUIDs are represented by unsigned integers and have an upper bound value.

  • Usable as random access index in constant time

Another aspect, and not less interesting is that the access to the information they identify can be done in constant time.

  • Recovering unused identifiers

A first implementation could consists in a monotonic counter.

The drawback of having a small size is that the number of unique identifier is more limited. This limit will finish by been reached if the application runs a long time. To palliate to this, we need a mechanism to recover the unused identifiers once the identified information is removed. Depending on the application the recovered identifiers should be discarded, reused immediately or frozen during a given duration or a number of times.

Usually they are reused in a first reusable first reused order (fifo), but depending on the implementation this could not be always the more efficient policy. So the user can either constraint this fifo order or let undefined this aspect.

  • Managing the lack of identifiers

In any case we need to manage with the overflow case, i.e. when there are no more free identifiers. The user could prefer an exception, return an invalid value, use errno, or call to a user defined function which could try to recover from this situation, by re dimensioning the upper bound for example.

  • Ensuring coherency on reusable identifiers

All this seams to work up to the user do not release the same identifiers twice. As this is an expensive aspect, but usually the applications has its own way to do it. If this is not the case the application could ask to the luid generator to ensure that.

  • Synchronization on multi threaded or multi process applications

The generation of new LUIDs and the recovering of unused LUIDs must be synchronized. So LUID are better adapted to systems where these operations are done in a reduced scope. Depending on this scope: single thread, multi-threaded process or a node,i.e. multiple process, the synchronization mechanisms vary. In a single thread scope no synchronization is needed. Synchronization on a multi-threaded process can be ensured using a thread mutex.

In addition the synchronization can be ensured internally by the generator, or externally by the user, i.e. the user has already a synchronization mechanism.

LUIDs are not adapted to distributed system (multiple nodes generating and recovering luids) because it needs a coordination between the different nodes which will take too much time. UUIDs and GUIDs are more adapted to this situation. Anyway if the size constraint can not be avoided, one of the nodes could play the master role and the others behaves as slaves. Master and slaves need to work together. This library do not pretend to take in account this use case but, could be the base of such approach.

  • Persistency

Another aspect is the lifetime of the information to be identified by the luids. It can be the lifetime of the process, the host machine lifetime or persists to a shut down of the host machine using the file-system.

  • Optimization

The last aspect will be the optimization. Different application have different needs, some have space constraints, and mot of the others have speed constraints.


Boost.Mirror

  • Author(s): Matus Chochlik
  • Version: 0.3.4
  • Last upload: February 9, 2009
  • Links:  Boost Vault  Boost Sandbox
  • Categories: Reflective Programming
  • Description: The aim of the Mirror library is to provide useful meta-data at both compile-time and run-time about common C++ constructs like namespaces, types (and as an important special case typedef-ined types), classes and their base classes and member attributes, instances, etc. and to provide uniform and generic interfaces for their introspection.

Boost.Move

  • Author(s): Adobe
  • Version:
  • State: stable
  • Last upload:
  • Links:  Boost Sandbox
  • Categories: Generic Programming Language Features Emulation
  • Description: User defined types often have remote parts either because they are implemented using a pointer-to-implementation or are variable sized. Such objects can be expensive to copy and are often copied unnecessarily when they are returned from functions or stored in other objects or containers. Boost.Move is a collection of utilities to implement types which can be moved to elide copying in such situations as well as utilities to assist in moving value.

Boost.MoveSemantics?


Boost.MPL.Ext


Boost.Msm

  • Author(s): Christophe Henry
  • Version: 1.10
  • State:
  • Last upload:
  • Links:  Boost Vault Boost Sandbox
  • Categories: Data Structures
  • Description: Msm is a framework which enables you to build a Finite State Machine in a straightforward, descriptive and easy-to-use manner . It requires minimal effort to generate a working program from an UML state machine diagram. This work was inspired by the state machine described in the book of David Abrahams and Aleksey Gurtovoy “C++ Template Metaprogramming” and adds most of what UML Designers are expecting from an UML State Machine framework(entry/exit actions, guards, composite states, orthogonal zones, history...).

Boost.Process

  • Author(s): Julio M. Merino Vidal
  • Version: v0.1
  • State:
  • Last upload:
  • Links:  Boost Sandbox
  • Categories: System
  • Description: Provides a flexible framework for the C++ programming language to manage running programs, also known as processes. Among other functionality, this includes the ability to manage the execution context of the currently running process, the ability to spawn new child processes, and a way to communicate with them them using standard C++ streams.

Boost.Plot

  • Author(s): Jacob Voytko & Paul A. Bristow
  • Version: v0
  • State: Under development, especially documentation, but usable.
  • Last upload: Jan 2009
  • Links:  Boost Plot
  • Categories: Image Processing
  • Description: Provides a way of plotting simple 1 and 2D graphs in Scalable Vector Graphic (svg) format directly from C++ code. The graphs are high quality when displayed on a wide variety of display sizes, from mobile phone to big screen, or when printed, but the graph files are tiny and fast enough to be done in near real-time. Fine control of appearance is provided in C++ (but with defaults and optional scaling of axes) so graphs can be produced in a very few lines of code. Current documentation is a mess but Very much improved documentation is nearly complete using Doxygen: meanwhile there are lots of examples.

Boost.Reflection

  • Author(s): Jeremy Pack
  • Version:
  • State:
  • Last upload:2008 Aug 08
  • Links:  Blog  Download  Boost Sandbox Headers  Boost Sandbox
  • Categories: Reflective Programming
  • Description: The goal of this library is to provide runtime reflection for C++ classes, and to allow the same across shared library boundaries. It is an offshoot of the Extension library, which provides dynamic class loading across shared libraries.

Boost.Reflection does not provide automatic reflection of classes. Instead, the class data must be manually reflected. This does offer some benefits however:

  • This can result in better performance, since only the necessary functions are reflected.
  • Arbitrary classes can be reflected without modification.
  • It is possible to make a reflected interface that is quite different from the original interface.

Boost.RendezVous

  • Author(s): Vicente J. Botet Escribá
  • Version: 0.0.0
  • State: Draft
  • Last upload: 2009 Fev 10
  • Links:  Boost Sandbox
  • Categories: Concurrent Programming
  • Description: Concurrent components may interact in different ways: they may access the same objects by, for example, executing functions of these objects; or they may communicate directly by executing functions of each other. These library will provide the so-called rendezvous mechanism for handling direct communication between active objects.

Boost.SmartPtr.UniquePtr

  • Author(s): Howard Hinnant <hinnant@…>
  • Version:
  • State:
  • Last upload: 2009 Jan 3
  • Links:  Documentation & Download
  • Categories: Generic Programming
  • Description: unique_ptr is a class template smart pointer currently in the  C++0X CD1 draft. It is intended to be a safer and more flexible replacement for auto_ptr. It represents sole (unique) ownership of a resource such as memory (like auto_ptr).

The actual C++0X unique_ptr makes use of a new C++ language feature called rvalue reference which is similar to our current reference (&), but spelled &&. This emulation is intended to capture most of the behavior of the C++0X unique_ptr but work with C++03 compilers. Furthermore this emulation makes use of boost library facilities and has been placed in the boost namespace. Though at the time of this writing, this library is not part of the official boost library release.


Boost.Synchro

  • Author(s): Vicente J. Botet Escribá
  • Version: 0.0.0
  • State: Draft
  • Last upload: 2009 Fev 10
  • Links:  Boost Sandbox
  • Categories: Concurrent Programming
  • Description:
    • Lock traits: very specific traits classes, some of them encapsulate a single trait for a Lockable type; for example, is a lock recursive (is_recursive), is useful in a multi threaded context (is_multi_threaded).
    • Finding the best lock: Inverse traits can match a lockable type based on specific traits, for a given family of lock types.
    • Synchronization family: A class that will do internal locking can be parameterized by the type of synchronization family needed to achieve the desired level of concurrency control. This depends of the usage scope of this class, and this can be mono_threaded, multi_threaded, multi_process.
    • Strict lockers: A strict_locker is a scoped lock guard ensuring the mutex is locked on the scope of the lock, by locking the mutex on construction and unlocking it on destruction.
    • External lockers: An alternative or complementary approach to internal locking is to support external locking for an object - Multiple calls may be grouped within the same externally defined critical region.
    • Reverse locker: reverse_lock.

Boost.ThreaderJoiner

This library works well with AsynchronousExecutors.


Boost.Tree


Boost.Unicode

  • Author(s): Graham Barnett & Rogier van Dalen
  • Version:
  • State:
  • Last upload: February 12, 2009
  • Links:  Boost Vault
  • Categories: String And Text Processing
  • Description: The Boost Unicode library aims to bring Unicode to C++ without requiring intricate knowledge of the Unicode standard, while allowing Unicode experts to do advanced things.

Other Open Source libraries

This page contains other libraries that work well with Boost.


ASL

  • Author(s): Sean Parent and Mat Marcus - Adobe
  • Version: 1.0.39
  • State: Released
  • Last upload: November 6, 2008
  • Links:  Home page
  • Description: Adobe Source Libraries (ASL) provides peer-reviewed and portable C++ source libraries. The libraries are intended to be widely useful, leveraging and extending both the C++ Standard Library and the Boost Libraries.

Poet

  • Author(s): Frank Mori Hess
  • Version:
  • State:
  • Last upload: June 25, 2008
  • Links:  Home Page
  • Categories: Concurrent Programming
  • Description: libpoet is a C++ parallel programing library. It provides support for easily creating active objects, creating monitor objects, and automatically validating mutex locking order.

Active objects provide concurrency and thread-safety, since each active object executes in its own thread. Futures are employed to communicate with active objects in a thread-safe manner. To learn more about the active object concept, see the paper "Active Object, An Object Behavioral Pattern for Concurrent Programming." by R. Greg Lavender and Douglas C. Schmidt. Some of the more important active object classes in libpoet are poet::active_function, poet::future, and poet::scheduler.

Monitor objects provide thread-safety via automatically locked access to an object. See the paper "Monitor Object, An Object Behavioral Pattern for Concurrent Programming" by Douglas C. Schmidt for more information about monitor objects. The poet::monitor_ptr, poet::monitor, and poet::monitor_base classes in libpoet provide support for monitor objects.

Finally, the poet::acyclic_mutex class provides a wrapper for mutex classes which adds automatic validation of a program's mutex locking order. Following a consistent locking order ensures your program will not deadlock due to problems such as "deadly embrace" or the "dining philosophers" problem.


TBB

  • Author(s): Intel
  • Version: 2.1
  • State: stable release
  • Last upload: June 7, 2008
  • Links:  Home page
  • Categories: Concurrent Programming
  • Description: Intel® Threading Building Blocks (TBB) offers a rich and complete approach to expressing parallelism in a C++ program. It is a library that helps you take advantage of multi-core processor performance without having to be a threading expert. Threading Building Blocks is not just a threads-replacement library. It represents a higher-level, task-based parallelism that abstracts platform details and threading mechanism for performance and scalability and performance.

Libraries Under Discussion

This page is an index page for discussion of possible libraries as people get their ideas together.


Libraries Wish list

This page contains libraries that people have requested of Boost (mostly on the developer's mailing list). If you're looking for a project, this is a good place to start.


Accumulators.Ext

  • Suggested by: Vicente J. Botet Escribá
  • Categories: Math And Numerics
  • Description: Adding sliding, dependable and cyclic accumulators to Boost.Accumulators.

The accumulator library allows to determine dependency between accumulator, but not between accumulator_sets. I would like to define an accumulator_set c so when we cumulate in two others c1 and c2 accumulator_set we cumulate also in c, some thing like:

typedef dependable_accumulator_set <double, ...> dependable_acc_type;

dependable_acc_type c1, c2;
dependable_acc_type c=c1+c2

dependable_acc_type c3;

c+=c3;

c1(1);
c2(1);
c3(2);
assert(count(c)==3);
assert(sum(c)==4);

How dependable_accumulator_set can be defined? Here follows the interfaces of such a class and the pseudo code, I've named the class dependable_accumulator_set, sorry but I have not found a shorter and better name (may be observed/listened?)

template <typename T, typename F, typename W>
class dependable_accumulator_set : public acumulator_set<T,F,W>
{
public:
    dependable_accumulator_set();
    void add_dependent(dependable_acumulator_set&);
    void remove_dependent(dependable_acumulator_set&);

    template<typename A1>
    void operator ()(A1 const &a1) {
        for (acc in dependents) {
            acc(a1);
        }
        this->accumulator_set_type::operator()(a1);
    }
    dependable_accumulator_set<T,F,W>& operator+=(dependable_accumulator_set<T,F,W>);
    dependable_accumulator_set<T,F,W>& operator-=(dependable_accumulator_set<T,F,W>);
};

template <typename T, typename F, typename W>
dependable_accumulator_set<T,F,W> 
operator+()(dependable_accumulator_set<T,F,W>,dependable_accumulator_set<T,F,W>);

Another variant could be also to have a temporary accumulator that cyclically push its current value on another accumulator.

It will also interesting to have a dependable and cyclic accumulator set. It would be great to integrate these features on a unique class (accumulator_set?) in a clean way.

template <typename T, typename F, typename W, 
          typename DependablePolicy, 
          typename CyclicPolicy>
class accumulator_set;

ConstraintsProgramming

  • Suggested by: Vicente J. Botet Escribá
  • Categories: []
  • Description: Constraints programming is a programming paradigm where relations between variables are stated in the form of constraints. Constraints differ from the common primitives of imperative programming languages in that they do not specify a step or sequence of steps to execute, but rather the properties of a solution to be found. This makes Constraint Programming a form of declarative programming.

typedef bounded<int, closed<1>, closed<2> > domain;
problem_solver<domain, domain> p;
p.add_constraint(_1 + _2 == 3);
for {problem::iterator it = p.solutions(); it != p.end(); ++it) {
    domain a, b;
    tie(a,b) = *it;
    std::cout << "[" << a << ", " << b << "]" << std::endl;
}

DenseSet

  • Suggested by: Vicente J. Botet Escribá
  • Categories: Containers
  • Description: Implementation of dense set of integers using intervals.

Frames

  • Suggested by: Vicente J. Botet Escribá
  • Categories: Input/Output
  • Description: Library based on an extension of the Archive concept making it bidirectional.

From wikipedia "A frame is a data packet of fixed or variable length which has been encoded by a data link layer communications protocol for digital transmission over a node-to-node link. Each frame consists of a header frame synchronization and perhaps bit synchronization, payload (useful information, or a packet at higher protocol layer) and trailer. Examples are Ethernet frames and Point-to-point protocol (PPP) frames."

The Boost.serialization saving archive concept allows to save serializable data at the end of the archive, and the loading archive concept allows to read serializable data from the beginning of the archive. The saving frame concept will allows to save serializable data either at the end or the begin of the frame, and the loading frame concept allows to read serializable data from the beginning or the end of the archive. I'm not sure which syntax will be the more appropriated. The serialization library use the <<, >>, and & operators that are associative from left to right. We need the equivalent operators from right to left. <<=, >>=, and &= seams to be the more natural candidates but I don't know if it is correct in C++ to define this operators with this prototype

template <typename T> frame& operator<<=(const T&, frame&);
template <typename T> frame& operator>>=(const T&, frame&);
template <typename T> frame& operator&=(const T&, frame&);
h1 >>= h2 >>= sf << t2 << t1

is equivalent to

(h1 >>= (h2 >>= ((sf << t2) << t1)))

and should be equivalent to

sa & h1 & h2 & t2 & t1

if sf and sa were empty.

The main difference is that we can do it hierarchically. The top layer will create a frame, and serialize its own information elements.

frame sf;
h_n >>= sf  << p_n << t_n;

Then this top layer will use a primitive of the lower level having as parameter the frame as payload.

primitive_n-1(sf);

A primitive at the k level will add its own header and trailer information element to the payload of the upper level

void primitive_k(frame& sf) {
    // ...
    h_k >>= sf  << t_k;
    // ...
    another_primitive_k_1(sf);
    // ...
}

So the frame allows to serialize top-down. To get the same result with the archive concept the serialization must be done bottom-up, needing to chain each one of the information element in a list and only when we have all off them we can start the serialization. I think that the frame approach should be more efficient because it avoid to store in dynamic memory the information elements to be serialized, instead they are serialized directly.

Loading a frame works as loading an archive, except that we can load also at the end of the frame. This avoids to load the complete archive to load the trailer of the lower levels.

lf >>= h_1;
// ...
t_1 << lf;

In addition, it would be great to have saving/loading frames (I'm not sure but I think that an archive can not be saving and loading at the same time). The same frame can be used as loading, analyzing only some lower levels, and as saving in order to construct other lower levels. This will be very useful for gateways and routers.

| L4 |<------------------------------>| L4 |
| L3 |    |     ADAPTATION     |      | L3 |
| L2 |<-->| L2 |          | X2 | <--> | X2 |
| L1 |<-->| L1 |          | X1 | <--> | X1 |

It would be great also that the same data that can be serialized on archives, could be serializable on a frame using the same save function. But this works only when we save at the end of the frame. Let me see this using a little example: Class C has 3 information elements to serialize (a, b and c). So the save functions could be something like

template <typename ARCHIVE>
void C::save(ARCHIVE& sa) {
    sa & a & b & c;
}

This save function works well from left to right, but can not be used when saving at the beginning of a frame, because the expected result when saving at the beginning is

a b c sa

but the result will be

c b a sa

So unfortunately we need a different save function

template <typename FRAME>
void C::save(FRAME& sa, begin_tag&) {
    a >>=  b >>= c >>= sa;
    // a >>=  (b >>= (c >>= sa));
}

Quartets

  • Suggested by: Vicente J. Botet Escribá
  • Categories: Containers Data Structures
  • Description: Quartet are half an octet, i.e. 4 bits taking values from 0..15, and usually represented by chars '0'-'9' 'A'-'F'. There are some container specializations as std::string, std::vector and boost::array that could be of interest to some applications. They are also used when a decimal number is encoded using the BCD format (binary coded decimal) or to encode telephone numbers.

SpreadSheet

  • Suggested by: Vicente J. Botet Escribá
  • Categories: []
  • Description: Allows to manage with the underlying concepts of a Spreadsheet but without displaying them.

Defines cells that can be organized in a classical grid consisting of rows and columns, or any other structure as for example a tree. Each cell could contains alphanumeric text or numeric values but can also contain any other value. A spreadsheet cell may alternatively contain a formula that defines how the contents of that cell is to be calculated from the contents of any other cell (or combination of cells) each time any cell is updated.

It seems natural to use Boost.Proto to define the DSL for the cell formulas.

space sh;
space::cell<int> c1(sh), c2(sh), c3(sh);
c1.expr=1;
c2.expr=2;
c3.expr=c1+c2;
sh.refresh();
std::cout<< c1.value() << ", " << c2.value() << ", " << c3.value() << std::endl;
sheet sh(2,3);
sheet::cell<int> c01(sh,0,1), c02(sh,0,2), c03(sh,0,3);
c01.expr=1;
c02.expr=2;
c03.expr=rel_cell(c03,0,1)+rel_cell(c03,0,2);
sh.refresh();
std::cout<< c01.value() << ", " << c02.value() << ", " << c03.value() << std::endl;
c11.expr=5;
c12.expr=8;
c13.expr=c03.copy(); 
sh.refresh();
std::cout<< c11 << ", " << c12 << ", " << c13 << std::endl;

StableVector

  • Suggested by: Joaquín M López Muñoz
  • Categories: Containers
  • Links:  Stable Vectors
  • Description: a container mimicking the interface of std::vector except that it provides iterator and reference stability at the expense of losing memory contiguity.

STM

  • Suggested by: Vicente J. Botet Escribá
  • Categories: Concurrent Programming
  • Description: Transactional memory (TM) is a recent parallel programming concept which reduces challenges found in parallel programming. TM offers numerous advantages over other synchronization mechanisms.

Abandoned


Boost.ConceptTraits

 Last Download

  • Description:Overload on Concepts of template parameter types, using enable_if and some class traits.

Libraries Listed by Category

See  Boost library documentation by Category for a list of the already approved Boost libraries by category.


Algorithms


Broken compiler workarounds


Concurrent Programming


Containers


Correctness And Testing


Data Communications


Data Structures


Database


Distribution


Function Objects And Higher-order Programming


Generic Programming


Graphical User Interface


Idioms


Image Processing


Input/Output?


Inter-language support


Iterators


Language Features Emulation


Math And Numerics


Memory


Parsing


Patterns


Portability


Preprocessor Metaprogramming


Programming Interfaces


Reflective Programming


String And Text Processing


System


Template Metaprogramming


Test


Utilities


XML


Miscellaneous