Re: [boost] type_traits: more state-of-the-union

From: John Maddock (john_maddock_at_[hidden])
Date: 2002-04-16 06:35:40

> 5. Okay, I figured out why is_empty was checking for int convertibility;
> it was for Borland. I restored the nasty check for that compiler.

Thanks, yes is_enum doesn't work there so that workaround is needed.

> 6. is_enum also seemed to rely on is_convertible, but there were no
> tests for is_enum<noncopyable> to uncover it. Fortunately there's an
> easy fix which I'm checking in.

OK

> 7. The header dependencies are getting messy. One striking example is
> created by the new is_class implementation, which is a standalone
> template on conforming implementations but relies on a huge number of
> other templates on other implementations. Add to that the fact that I
> can never remember which header contains is_enum, etc., and I am coming
> to the conclusion that a fine-grained header structure with one header
> per template is the way to go. Otherwise, it seems to me that any user
> of type traits is going to essentially get the whole wad regardless of
> the fact that she's using the current "fine-grained" headers.

There are so many *?*! workarounds that's the problem :-(
You are right though, we may need to rework the headers sometime.

> 8. I think we need some new config macros, but I'd like someone who has
> done this before to add them if possible
>
>     BOOST_ELIPSIS_ARGS_DO_NOT_INVOKE_COPY_CONSTRUCTOR - for compilers
> that can resolve overloads to functions accepting elipsis arguments
> without invoking the copy constructor of the actual argument. This is
> nonconforming behavior AFAICT but most compilers seem to allow it, and
> it's what allows is_convertible<T,U> to work when T is noncopyable.

I think we can fix that by not passing object through elipses in
is_convertible - see gcc implementation.

John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm