Re: [boost] Re: Re: is_class

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-02-16 08:29:25

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: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de