I was trying out some CUDA/Thrust code on Linux/GCC and wanted to use some TR1 libraries, when I noticed something peculiar: Most libraries will invariably pull in tr1_impl/type_traits
(4.4) or just type_traits
(4.6), and that header will always contain variadic templates, like so:
template<typename _Res, typename... _ArgTypes>
struct is_function<_Res(_ArgTypes...)>
: public true_type { };
However, these headers also get used when I run GCC in C++98 or C++03 mode! How can this work?
The actual problem I encountered is that the CUDA toolchain doesn't recognize C++0x constructions, and cudafe++
(the CUDA front end, i.e. the pr开发者_如何学编程ogram that separates the joint source code into host and device source code) rightly aborts with an error when encountering the variadic template parameter.
So... how can GCC support and rely on variadic templates in non-0x dialects of C++? And is there a way to obtain a genuine C++03 version of TR1?
Welp, an implementation is not required to provide headers. It's required that an #include <stuff>
does The Right Thing. So that means that if an implementation decides to use headers for this functionality, it's not required that those headers be conforming C++. And in fact GCC has supported variadic templates as an extension for quite some time.
Furthermore, I can't help but notice
#pragma GCC system header
in the <tr1/random>
header that you mention. GCC will treat the file specially, and e.g. not report errors warnings in it. I would have thought using an extension in conforming mode can easily be turned into an error so I'm not sure what's going on but at least legally it's an option.
There's also the special status of TR1, which is not binding. On my implementation as far I can tell the only C++03 header that includes <type_traits>
is <functional>
and it properly only does that in C++0x mode (i.e. the rest of the time it's a valid C++03 file via preprocessing, unlike <tr1/random>
). (I didn't check for other cases though.)
精彩评论