Re: [boost] Re: Re: Re: An alternative typeof macro

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
<vertleyb_at_[hidden]> wrote:
> "Peder Holt" <peder.holt_at_[hidden]> wrote
> 
> > 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.
> 
> 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
> them).
> 
> 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
> mpl::vectorN<>.
> 
> 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
>