From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-09-01 10:53:16
"David Abrahams" <dave_at_[hidden]> wrote
> Peder Holt <peder.holt_at_[hidden]> writes:
>
> > On 9/1/05, David Abrahams <dave_at_[hidden]> wrote:
> >> Eric Niebler <eric_at_[hidden]> writes:
> >>
> >> > Ah. But the fact remains that remove_pointer et al. are indeed broken
on
> >> > VC6 and VC7, and the regression tests bear this out.
> >> >
> >> > http://tinyurl.com/8fs7w
> >> >
> >> > IMO, the best path is to preserve the meaning of
> >> > BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION for compilers
without
> >> > PTS. That is, it still defines full specializations of the type
traits
> >> > templates. But the typeof implementation should be what the primary
> >> > template uses for compilers without PTS. That way, everything that is
> >> > working now, keeps working with no change in performance.
> >>
> >> I think it would better to do some actual speed testing there. After
> >> all, using the typeof hack *could* turn out to be much faster and use
> >> fewer resources than doing it the other way.
> >>
> >> It's a pretty easy test.
> >
> > I don't think using the typeof library directly is the best idea. When
> > using typeof, you represent each type by a number, limiting you to
> > ~1000 types.
>
> I hope that's false, but in any case, you've completely missed the
> point. There's a bugfeature in vc <= 7.1 that allows typeof to be
> implemented without any such limitation. No numerical representation
> is ever generated.
I think Peder is right. IIRC, when Igor Chesnokov invented the trick, it
needed __if_exist compiler extension on VC7. Peder got rid of it using
compile-time variables (discussed on this list about a year ago). I think
these compile-time variables are used to "register" types on the fly, at the
moment typeof gets invoked. And they are the ones that introduce this
limitation...
I am not sure if the same limitation applies to VC6. I am also not
completely sure whether it applies to both VC70 and VC71 or to VC71 only...
Regards,
Arkadiy