Anthony Williams

Tom Brinkman

This library proposes a kind of return buffer that takes a value (or an exception) in one (sub-)thread and provides the value in another (controlling) thread. This buffer provides essentially two interfaces:

• an interface to assign a value as class promise and
• an interface to wait for, query and retrieve the value (or exception) from the buffer as classes unique_future and shared_future. While a unique_future provides move semantics where the value (or exception) can be retrieved only once, the shared_future provides copy semantics where the value can be retrieved arbitrarily often.

A typical procedure for working with promises and futures looks like:

• control thread creates a promise,
• control thread gets associated future from promise,
• control thread starts sub-thread,
• sub-thread calls actual function and assigns the return value to the promise,
• control thread waits for future to become ready,
• control thread retrieves value from future.

Also proposed is a packaged_task that wraps one callable object and provides another one that can be started in its own thread and assigns the return value (or exception) to a return buffer that can be accessed through one of the future classes.

With a packaged_task a typical procedure looks like:

• control thread creates a packaged_task with a callable object,
• control thread gets associated future from packaged_task,
• control thread starts sub-thread, which invokes the packaged_task,
• packaged_task calls the callable function and assigns the return value,
• control thread waits for future to become ready,
• control thread retrieves value from future.

Robert Kawulak

Jeff Garland

http://rk.go.pl/f/constrained_value.zip

The Boost Constrained Value library contains class templates useful for creating constrained objects. A simple example is an object representing an hour of a day, for which only integers from the range [0, 23] are valid values:

bounded_int<int, 0, 23>::type hour;
hour = 20; // OK
hour = 26; // exception!

Behavior in case of assignment of an invalid value can be customized. For instance, instead of throwing an exception as in the example above, the value may be adjusted to meet the constraint:

wrapping_int<int, 0, 255>::type buffer_index;
buffer_index = 257; // OK: wraps the value to fit in the range
assert( buffer_index == 1 );

The library doesn't focus only on bounded objects as in the examples above -- virtually any constraint can be imposed by using a predicate:

// constraint (a predicate)
struct is_odd {
   bool operator () (int i) const
   { return (i % 2) != 0; }
};

// and the usage is as simple as:
constrained<int, is_odd> odd_int = 1;
odd_int += 2; // OK
++odd_int; // exception!

The library has a policy-based design to allow for flexibility in defining constraints and behavior in case of assignment of invalid values. Policies may be configured at compile-time for maximum efficiency or may be changeable at runtime if such dynamic functionality is needed.

Oliver Kowalke

Needed

Boost Sandbox Vault

The library provides:

• thread creation policies: determines the management of worker threads

  • fixed set of threads in pool
  • create workerthreads on demand (depending on context)
  • let worker threads ime out after certain idle time

• channel policies: manages access to queued tasks

  • bounded channel with high and low watermark for queuing tasks
  • unbounded channel with unlimited number of queued tasks
  • rendezvous syncron hand-over between producer and consumer threads

• queueing policy: determines how tasks will be removed from channel

  • FIFO
  • LIFO
  • priority queue (attribute assigned to task)
  • smart insertions and extractions (for instance remove oldest task with certain attribute by newst one)

• tasks can be chained and lazy submit of taks is also supported (thanks to Braddocks future library).

• returns a task object from the submit function. The task it self can be interrupted if its is cooperative (means it has some interruption points in its code -> this_thread::interruption_point() ).

Pawel Kieliszczyk

Needed

Boost Sandbox Vault

The library was written to enable fast and faithful polynomial manipulation. It provides:

• main arithmetic operators (+, -, * using FFT, /, %),
• gcd,
• different methods of evaluation (Horner Scheme, Compensated Horner Algorithm, by preconditioning),
• derivatives and integrals,
• interpolation,
• conversions between various polynomial forms (special functions for creating Chebyshev, Hermite, Laguerre and Legendre form).

Matus Chochlik

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, typedef-ined types, classes and their base classes and member attributes, instances, etc. and to provide generic interfaces for their introspection.

Mirror is designed with the principle of stratification in mind and tries to be as less intrusive as possible. New or existing classes do not need to be designed to directly support Mirror and no Mirror related code is necessary in the class' definition, as far as some general guidelines are followed

Most important features of the Mirror library that are currently implemented include:

• Namespace-name inspection.
• Inspection of the whole scope in which a namespace is defined
• Type-name querying, with the support for typedef-ined typenames and typenames of derived types like pointers, references, cv-qualified types, arrays, functions and template names. Names with or without nested-name-specifiers can be queried.
• Inspection of the scope in which a type has been defined
• Uniform and generic inspection of class' base classes. One can inspect traits of the base classes for example their types, whether they are inherited virtually or not and the access specifier (private, protected, public).
• Uniform and generic inspection of class' member attributes. At compile-time the count of class' attributes and their types, storage class specifiers (static, mutable) and some other traits can be queried. At run-time one can uniformly query the names and/or values (when given an instance of the reflected class) of the member attributes and sequentially execute a custom functor on every attribute of a class.
• Traversals of a class' (or generally type's) structure with user defined visitors, which are optionally working on an provided instance of the type or just on it's structure without any run-time data. These visitors are guided by Mirror through the structure of the class and optionally provided with contextual information about the current position in the traversal.

I'm hoping to have it review ready in the next few months.

Joachim Faulhaber

The Interval Template Library (Itl) provides intervals and two kinds of interval containers: Interval_sets and interval_maps. Interval_sets and maps can be used just as sets or maps of elements. Yet they are much more space and time efficient when the elements occur in contiguous chunks: intervals. This is obviously the case in many problem domains, particularly in fields that deal with problems related to date and time.

Interval containers allow for intersection with interval_sets to work with segmentation. For instance you might want to intersect an interval container with a grid of months and then iterate over those months.

Finally interval_maps provide aggregation on associated values, if added intervals overlap with intervals that are stored in the interval_map. This feature is called aggregate on overlap. It is shown by example:

typedef set<string> guests;
interval_map<time, guests> party;
guests mary; mary.insert("Mary");
guests harry; harry.insert("Harry");
party += make_pair(interval<time>::rightopen(20:00, 22:00),mary);
party += make_pair(interval<time>::rightopen_(21:00, 23:00),harry);
// party now contains
[20:00, 21:00)->{"Mary"}
[21:00, 22:00)->{"Harry","Mary"} //guest sets aggregated on overlap
[22:00, 23:00)->{"Harry"}

As can be seen from the example an interval_map has both a decompositional behavior (on the time dimension) as well as a accumulative one (on the associated values).

Vicente J. Botet Escriba

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 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 groupe where the number of threads is know statically and the threads are created at construction time.
• set_once: a synchonizer 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.

Boost.InterThreads extends Boost.Threads adding thread setup/cleanup decorator, thread specific shared pointer, thread keep alive mechanism and thread tuples.