Re: [boost] How to structurate libraries ?

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 ;)).