Jody Hagins wrote:
The coding guidelines document (boost/more/int_const_guidelines.htm), states the following...
Always use a fully qualified name to refer to an integral constant expression.
For example:
typedef myclass< ::boost::is_integral<some_type>::value> mytypedef;
Rationale: at least one compiler (Borland's), doesn't recognise the name of a constant as an integral constant expression unless the name is fully qualified (which is to say it starts with ::).
However, it appears that the same compiler (BCB6) has problems if the '::' is left in. For example...
template <class T> struct Foo { typedef typename ::boost::remove_reference< T >::type type; typedef typename ::boost::add_reference< typename ::boost::add_const< type >::type >::type ref_to_const_type; };
fails to compile. Initially I thought it had something to do with typename (e.g., another BOOST_DEDUCED_TYPENAME) because, the first, simpler line compiles if I remove the "typename" keyword. Unfortunately, the following does not compile either
Well, this is neither a deduced context nor does it involve ICEs. Besides, as you might know, BCB has problem detecting dependent types and thus removing typename is always a good idea before suspecting other evil. There is really no point in always fully qualifying every name you use. Only do so when referring to a static member constant! In fact, the easiest way is to avoid non-type template arguments whenever possible and pass around types instead (see MPL Integral Constant Concept). When the compiler substitutes a template type paramter with its argument it is "fully qualified automatically": template<typename IC> struct X { // using IC::value is fine, here } This technique could make some Type Traits code more readable, I guess. Further, some passages might be overly careful..
So, I am left scratching my head, wondering what to do if I want to use TypeTraits in a portbale manner.
Fully qualify only when referring to static member constants. Regards, Tobias