John Maddock wrote: > > > typedef test::remove_pointer< int A::* >::type t1; > > typedef test::remove_pointer< int A::* const >::type t2; > > typedef test::remove_pointer< int A::* volatile >::type t3; > > typedef test::remove_pointer< int A::* const volatile >::type t4; > > Those should not work: or maybe you want them to do nothing? Whatever you > can't remove the pointer from a member pointer because the result is not a > valid type. However the boost implementation should compile (so it's a > bug), I'll look into it when I get some space.
I think that it should return 'int' in the case above. It's useful when you have a member variable pointer and want to deduce the type that it points to to make a copy of it. I don't see why this should not work. Of course you have to differentiate between member variable pointers and member function pointers, the latter might be a problem. But as a general rule, I think type-traits should always compile if possible. When a user needs to check if the pointer was really removed, is_same can help to find that out. Something like: BOOST_STATIC_ASSERT(( !boost::is_same< T, remove_pointer< T >::type >::value )); In this case, is_pointer should work too, but the above shows a general implementation that can also be used in other cases. The user can easily add it to his code if he wants to, but we shouldn't put such a limitation inside the implementation by design. > > typedef test::add_const< int( int ) >::type t5; > > typedef test::add_volatile< int( int ) >::type t6; > > typedef test::add_cv< int( int ) >::type t7; > > That compiles but emits warnings on gcc, fails to compile on other > compilers, the docs say: "The same as "T const" for all T" which means that > function types are effectively banned (because cv-qualifed functions are > banned), we can filter the template through is_function to avoid that > though - I'm not sure how common the situation would be though. The documentation should IMHO read: "The same as "T const" for all T that can be const-qualified or "T" otherwise". This would reflect the exception that was already made for references. And something similar is probably useful for other traits, too. > > typedef char t8[ test::is_convertible< double, int >::value ]; > > That one issues a warning: for other compilers we are able to suppress that, > if you have any ideas on how to do so with gcc I'd be happy to hear about > it. In my implementation, I just checked for is_float< T > and is_integral< U > and returned true. Only if this condition isn't given, I instantiate the "real" check. > > typedef char t9[ !test::is_class< int( int ) >::value ]; > > Generates warnings on gcc only, these have been reported and confirmed as a > gcc bug: > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&p > r=8503 > > > typedef char t10[ !test::is_enum< int( int ) >::value ]; > > again that's a gcc 3.2 bug. Yes, and like is_convertible above, I simply checked for is_function in my implementation before instantiating is_class or is_enum. Getting type-traits right is IMHO mostly a question of dependencies. What is created first and what can be used to implement other type-traits. > There's always interest - but please remember that: > > a) we have limited time for testing new ideas - the more you can do to make > this easy the better, especially as there is a new boost release imminent, > along with a deadline for committee meeting papers real soon now :-( > b) experience suggests that almost any changes to type traits break > something, sorry but that's the way it is. Yes, I understand that. I think that the type-traits are probably one of the most fragile parts of boost as it hits a lot of compiler bugs. But this is exactly the reason why I think that all the workarounds and techniques used need more documentation. Otherwise no one except you and maybe 3 others will be able to work on it in the future. > c) several of your ideas I did test on other compilers, but didn't get very > far (I should have reported this before, sorry) your is_function version > doesn't work with any of the popular win32 compilers for example - and yes I > know that the standard says that it should work :-( That is the kind of information I was hoping for. Thank you very much. Sadly, the result is not what I hoped for. I'll look at it closer if I'm back at home and have some more time. Regards, Daniel PS: Sorry if I was more frustrated than appropriate, but there were also some things outside of boost that frustrated me and it all came at the same time. Murphy's law I guess. Apologies to those that I griped to. -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
