Hi Arkadiy, Arkadiy Vertleyb wrote:
Hi Tobias,
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote
I don't like the '_TPL' suffix - I'ld prefer 'TEMPLATED' to be spelled out.
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
actually, I meant BOOST_TEMPLATED_TYPEOF and BOOST_TEMPLATED_LVALUE_TYPEOF, 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:
#define BOOST_TYPEOF_REGISTRATION <table> #include BOOST_TYPEOF_REGISTER()
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": http://www.boost.org/libs/preprocessor/doc/terms/named_external.html http://boost-consulting.com/tmpbook/preprocessor.html#vertical-repetition I'm talking about making the client code for the registration look like this (e.g.): #define BOOST_TYPEOF_REGISTRATION \ ( 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 ! Regards, Tobias