[boost] Re: An alternative typeof macro

From: David Abrahams (dave_at_[hidden])
Date: 2004-09-02 05:40:12

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.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com