Boost logo

Boost :

Subject: Re: [boost] How to structurate libraries ?
From: Joel Falcou (joel.falcou_at_[hidden])
Date: 2009-01-15 09:02:51


Andrew Sutton a écrit :
> I was wondering when somebody would build something like this...
Indeed ;)

> I think a first version would be a larger framework - or a collection of the
> smaller libraries (Boost.Arch?). That gives a focal point for reviewing, and
> the libraries can be broken out or the elements migrated later.

Well, maybe having a structure like Boost.math then ?
Currently planned library (some in dev., some done) includes:

* Arch.Memory : Provides free function and STL compatible allocators for
aligned memory allocation and a macro to add aligned new/delete support
into classes. Basically a platform independant wrapper around
posix_memalign and its ilk.

* Arch.Types: some low level traits and generation class including
things like :
  -> make_integer that build an integer type able to hold at most N
bytes and with a given signedness e.g : make_interger<3,signed>::type
returns int32_t.
  -> typed_bitfield that wraps a type T and a properly sized byte array
and provide proper byte access operator[]. Useful for decomposing large
types into bytes for low level operations.
  -> padded<T,N> that provides an Enveloppe/Letter class around type T
and whose sizeof is so that it's padded to a multiple of 2^N. It reuses
compressed_pair for empty-base class optimisation.

* Arch.SIMD : a SIMD computation library that provides a small scale
binding to internal representation of a SIMD register on SIMD-enabled
machine. Using Proto, a small DSEL is provided so one can write code like :

vec<float> k = {5,5,5,5},r;
r = ((2*k)/(3-k)).min();

and have vec generate a proper SSEx or Altivec code. This also require
some large config code to be added so we cna detect which extension
can/is being used. Traits like is_simd, cardinal, vector_of, scalar_of
are provided. Current plan is to see if vec can also act as some Fusion
container and to see how to properly optimize fused operation (have an
actual PHD student on this) and make it easily extensible for upcoming
SIMD extension (including AVX, SSE5 or Cell SPU).
-> Depends on Memory and Types

Some others maybe done I think adn some that are not meant to be there
(like a eval_as meta-function that cna compute numarical data
computation result_of) , but that's what I have at hand so far.

So I guess a proper clean-up of those thingy need to be done before
being uploaded onto the vault (hoping they'll raise more interest than
my punny type ID library ;)).


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk