Hi Tobias, Thanks for the review. "Tobias Schwinger" <tschwinger@neoscientists.org> wrote
I don't like the '_TPL' suffix - I'ld prefer 'TEMPLATED' to be spelled out.
Making libraries work with Boost.Typeof implies collecting a lot of information about types and templates which could be useful in other places as well: For example it would be possible to collect the names as well (and require
to be fully qualified) to allow an efficient "compile time type info" facility to be built upon it. There might be more interesting ideas in this
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 using mpl::identity<__typeof__(x)>::type to wrap native typeof, I thought we can get rid of the xxx_TPL macros altogether (which would be a preferable solution for me), but now I realize that "typename" is used twice in the macto expansion. Which means we may also need BOOST_LVALUE_TYPEOF_TPL (or analogous). I need to give this a little more thought, and I also like to hear what other people think about naming. them direction
(and that's the primary reason for me to mention it here).
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
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... the
registration data:
#define BOOST_TYPEOF_REGISTRATION <table> #include BOOST_TYPEOF_REGISTER()
Not sure I understand this... Can you ellaborate?
I didn't have any problems with my primary compilers, which are among the officially supported ones and did some testing on my secondary computer (running linux) while writing this review:
All tests failed with Intel 7.0 and Intel 8.1 ("no instance of function template boost::type_of::at matches the argument list * - in BOOST_TYPEOF_TPL").
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. Regards, Arkadiy