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
> 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
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 >
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk