Re: [boost] mpl , tuples, compile-time and run-time

From: Bernard (yahoo_at_[hidden])
Date: 2003-11-14 07:13:51

Bonjour ,
Le Vendredi 14 Novembre 2003 00:05, Joel de Guzman a écrit :
> Hi Bernard,
...
>
> Ok, so you have an mpl sequence that you want to build a tuple
> from? Is that it?

Kind of. I've a tuple of M input tuples of different sizes. I want to 
build a tuples made of the Nth elements of the input tuples. If K 
input tuples do not have a Nth elements because they are too small, 
then my resulting tuple should be of size M-K.

>
> > It seems I should be able to conditionally instanciate fetching
> > functions, but I do not really see how to do it and I'd hate to
> > discover that some booster already did it much better.
>
> Perhaps.

Indeed ! as usual :-)

>
...
> There's a library (currently in the boost-sandbox under the spirit
> directory) code-named fusion. It is a work in progress based on the
> TR1 tuple implementation that Jaakko and I wrote a few months ago
> (also in the boost-sandbox). This is a re-implementation of the TR1
> tuples with iterators, views and algorithms. The structure is
> somewhat modeled after MPL. I code-named it "Fusion" because the
> library reminds me of the "Fusion" of compile time metaprogramming
> with runtime programming.

It looks really great and just what I needed.
I think filter_view (selecting tuples Nth elements that are not of 
tuples::null_tupe) and generate (making the resulting tuple seleting 
the N'th element of each filtered tuple) are what I wanted.

I still have one remaning question about compile-time & runtime mix a 
la Fusion:
Having to provide both computed return type and computed return value, 
am I right in thinking that inheriting from the fusion "composite 
view class" the simplest way to do it ?

(for example:
template<typename N, typename TupleOfTuples>
struct select_Nth_view : 
transform_view<filter_view<tuple_view<TupleOfTuples>, ... >{};

The problem is that I need to store the result, so I need to know it's 
type.

>
> Right now, I'm working on making it feature complete plus
> documentation, and the tough part--porting to vintage compilers

I might sound selfish, but I'd be sorry to way for the crippled 
compilers port :-(
The good reasons not to release should be:
1) lack of API stability (would be most frustrating for early users to 
have their code broken by next release)
2) lack of documentation, less important because at least people know 
upfront that the documentation is lacking (unlike reason 1) where 
users discover later that code no longer works)

Crippled compilers support can always be added latter as it should not 
break the API.

> (VC6 and borland). Check it out. See the readme file for a brief
> synopsis on what's available.

Very impressing ! Kudos for the great code !

Thank you very much for your work, and your reply.

Bernard