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

From: Joel de Guzman (joel_at_[hidden])
Date: 2003-11-14 09:52:47

Bernard <yahoo_at_[hidden]> wrote:

> 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>, ... >{};

I think that's a good strategy. Have you tried it?

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

Right. I also had this same discusion with Daniel Wallin in a private
email.

'''
In many cases, you'll need the tuple result type from the "generate" function.
The generated tuple type metafunction will be a public API. The one in
the sandbox is private. It should something like:

    typedef result_of_generate<view>::type tuple_type;

if you need the type generated by "generate" now, you can temporarily
use:

    tuple_detail::generate_tuple<
        typename ViewT::begin_type
      , typename ViewT::end_type
    >::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)

Well, I have to say that the API is not stable yet. That's obvious ;-)
There will still be changes. For instance, tuple_view is no longer
necessary since tuple<...> *is a* conforming sequence. I expect a few
more API changes in the near future. However, I think the changes
will be cosmetic. I can say that the scheme and concepts are rather rock
solid now.

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

I'm working on it. No promises, but I hope to churn out one soon. Well,
I'm also working on Spirit v1.8.0 right now so I really can't promise
when I can come up with some docs.

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

Well, it is hoped that this will replace the current tuples library which
is getting rather inadequate and outdated. As such, it must provide,
at the very least, backward compatibility. This means support for VC6
VC7 and borland.

<<BTW, is it just me? It seems that the current tuples lib does not compile
on borland 5.5.1 anymore? >>

--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net