Re: [boost] Re: An alternative typeof macro

From: Peder Holt (peder.holt_at_[hidden])
Date: 2004-09-02 07:13:53

On Thu, 02 Sep 2004 06:40:12 -0400, David Abrahams
<dave_at_[hidden]> wrote:
> Peder Holt <peder.holt_at_[hidden]> writes:
> 
> > On Wed, 1 Sep 2004 11:36:16 -0400, Arkadiy Vertleyb
> > <vertleyb_at_[hidden]> wrote:
> >> "Peder Holt" <peder.holt_at_[hidden]> wrote
> >>
> >> > Ok. I see what you do, and agree that on newer compilers, your code is
> >> > of the order O(N) (with your newest adjustments, even O(m))
> >> > I also see that your implementation requires the use of mpl, as you
> >> > require random access to the list of generated integers. This
> >> > introduces the before mentioned mpl limit of 60 (or around there)
> >> > which it turns out is difficult to bypass.
> >>
> >> It's not really difficult (see
> >> http://lists.boost.org/MailArchives/boost/msg10949.php).  I will
> >> probably stop using BOOST_MPL_LIMIT_VECTOR_SIZE, and introduce my
> >> own #define, something like BOOST_TYPEOF_LIMIT_SIZE.  Then I will
> >> generate necessary vector definitions based on this limit.
> >
> > The problem with this is compile times. As the message thread
> > specified above.  This will causes the preprocessor to generate a
> > lot of code (for vector1,vector2,vector3,vector4 etc. etc), causing
> > the compile times to plummet as the vector size goes up.  Also, you
> > force all users of typeof to work with very large mpl vectors. I am
> > not so sure this would be a generally accepted penalty for working
> > with typeof...
> >
> > My guess is that implementing a linked list, and searching for the
> > element at position N would require less compile time.
> 
> MPL vectors contain optimizations that a naive type vector (and
> _especially_ a typelist) does not, so I wouldn't be so confident about
> that prediction.  But why guess?  Benchmark it yourself.
> 
> Oh, and test it against the mplbook branch of boost/mpl, so you get
> an accurate view of the next release.
> 
> > Alternatively, make your own vector type, with a predefined
> > BOOST_TYPEOF_LIMIT_SIZE number of arguments. mpl::vector is a general
> > type vector with many advanced features.
> > All you really need is to know the integral value at position N.
> 
> You mean iterators?  What makes you think their presence is going to
> cause compilation to slow down?  This is starting to ring of MPL FUD.
> 

I agree. I will do some more research before I criticise mpl for being
overweight. Sorry.
My other comment still stands, though. When
BOOST_MPL_LIMIT_VECTOR_SIZE is increased to encompass more parameters
for typeof, this will affect the compile times for other uses of
mpl::vector in the project as well.

--
Peder Holt
> --
> Dave Abrahams
> Boost Consulting
> http://www.boost-consulting.com
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>