From: Peder Holt (peder.holt_at_[hidden])
Date: 2004-09-02 09:03:35
On Thu, 2 Sep 2004 09:24:11 -0400, Arkadiy Vertleyb
> "Peder Holt" <peder.holt_at_[hidden]> wrote
> > The problem with this is compile times. As the message thread specified
> > 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.
> Note that this is done once per compilation unit (and can be easily taken
> care of by the pre-compiled headers feature on the systems that support
> When considering performance we should clearly separate what's happenning
> once per translation unit, and what's happenning on the per-typeof
> invocation basis.
> Please also note that your "compile-time variables" require to instantiate a
> template (or maybe even 3 templates) every time a variable is set.
> > Also, you force all users of typeof to work with very large mpl
> > vectors.
> I don't think so. As I said, I will most likely stop using
> BOOST_MPL_LIMIT_VECTOR_SIZE, and use my own limit N to directly work with
> And as far as I understand MPL, the fact that I am working with, e.g.,
> mpl::vector256<> doesn't prevent other facilities in the same translation
> unit from using mpl::vector3<>.
Ok. I agree. If you work directly on the vectorN templates,
mpl::vector is not affected.
Given the need for random access, mpl is probably the best choice
after all. I'll do some research on your code (when I get the time,
and you have the new version ready) to test some of my ideas to see if
I have a point or not :)
-- Peder Holt > > > Regards, > Arkadiy > > _______________________________________________ > 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