Re: [boost] New implementation of remove_xxx for vintage compilers

From: Peder Holt (peder.holt_at_[hidden])
Date: 2005-09-01 13:13:22

On 9/1/05, Arkadiy Vertleyb <vertleyb_at_[hidden]> wrote:
> "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...

That's right. the typeof trick requires an unique identifier to be
'registered' for every new type  invoked. In the typeof library, we
use an integral constant. This is because the type is registered
inside a function, and the only thing we can extract compile-time from
a function is an integral constant using sizeof.
It would perhaps be possible to use a more elaborate scheme, where two
distinct compile-time constants are combined to increase the limit,
but we have to take into account that this limit applies on a
per-compilation-unit basis, and a compilation unit containing ~1000
typeof invocations of 1000 different types would probably exhaust the
compiler anyway (at least in emulation modus)

> 
> 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...
> 

Currently the limitation applies to all three compilers, but the limit
of 1000 is arbitrary.

I read through an email I got from Igor on the subject, and he wrote:
"... Also, limit of __if_exists/__if_not_exists counter is
greater than 1000, but when it exceeds 2500+ compiler generates "internal
structure overflow"."

Regards,
Peder

> 
> Regards,
> Arkadiy
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>