Re: [boost] Proposed metaprogramming type system

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-12-17 10:07:21

From: "Fernando Cacciola" <fcacciola_at_[hidden]>
[...]
> > (Rationale: practice shows that attempting to cover compile-time values
as
> > well results in excessive duplication. ct_value<> is chosen to avoid
> having
> > separate bool_t, int_t, uint_t, size_t_t and so on.)
> >
> This is very useful for Borland, since it has so poor non-type template
> parameter support.

Yes, this is the main problem with ct_value. Should we cripple the interface
because some compilers don't conform now? Tough question.

> > The primary data structure is a binary tree represented by pair<Left,
> > Right>. The most common special case is the list, defined recursively
as:
> >
> > * nil is a list, called the empty list.
> > * pair<F, R> is a list iff R is a list.
> >
> > No type defined by the library, except ct_type<T>, is guaranteed to have
> an
> > accessible constructor (or be a complete type) unless stated otherwise.
>
> And ct_value<> ?

Yes, probably; depends on whether Andrei would like to adopt ct_value<int,
N> instead of int2type<N>.

> I wonder if suffixing 'v' and 'q' to 'funtion' could look awkard with some
> specific functions names...
> How about suffixing 'ct' instead:  ctv_if<>, ctq_if<>...

Not every function has ct_ in front (mpl:: is enough to disambiguate), but
most still would have a quoted form.

--
Peter Dimov
Multi Media Ltd.