Boost logo

Boost :

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-05-21 05:07:44

Hi Arkadiy,

Arkadiy Vertleyb wrote:
> Hi Tobias,
> "Tobias Schwinger" <tschwinger_at_[hidden]> wrote
>>I don't like the '_TPL' suffix - I'ld prefer 'TEMPLATED' to be spelled
> I don't have strong feelings about our current spelling, but I am not sure
> if I am crasy about BOOST_TYPEOF_TEMPLATED either. When David suggested

which read and speak better...

> I need to give this a little more thought, and I also like to
> hear what other people think about naming.

...but don't claim these names to be perfect, of course.

> Agreed. Also I think Steve Dewhurst (who apparently did a lot of research
> in this area) once published an article about decomposing a type and
> bringing it back together...

Are you talking about the 'typeints'- or the 'typeof'-article ?
Can you perhaps post a link ?

>>In the registration interface there is no way to get rid of the one
>>#include per file, so I would prefer a table passed as "named external
>>argument" for the registration data:
> Not sure I understand this... Can you ellaborate?

First of all I have to "fix a bug" in my previous post: it does not point to the
definitions or at least to the documentation of Boost.Preprocessor to explain
the terms "named external argument" and "vertical repetition":

I'm talking about making the client code for the registration look like this (e.g.):

                ( typename(boost::lambda::greater_action) ) \
                ( template(boost::lambda::functor,1) ) \
                 ( template(boost::lambda::lambda_functor_base,2) ) \
        #include BOOST_TYPEOF_REGISTER()

This way you don't need a registration group to create unique indices for all
registered templates/types. All you need to do is store the last index
incremented by one as the first index for the next run (i.e. #inclusion) and
the user isn't required to remember incrementing the registration group.
Further I mentioned the possibility to trade some preprocessing performance for
convenience and transparency, which may or may not be desirable.

> We did some work with Aleksandr Nasonov to port the library to Intel 8.0,
> and we came pretty close -- only the exotic case "template<class T, Tn>"
> didn't work, and we proved to ourselves that this was because of the
> compiler bug. So I think Intel will be among first compilers to extend our
> support.

Good to hear it's a compiler bug. Btw. I had to do something like this once and
got away with member templates:

        template<typename T> class X { template<T n> [...]

(IIRC this works with Intel) and to be honest I didn't even know it is a valid
possibilty to do it within a single template parameter list, until now (well,
don't know for sure - I just believe you ;-) ).

> Thanks for the review.

Thanks for the library !



Boost list run by bdawes at, gregod at, cpdaniel at, john at