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

From: Peder Holt (peder.holt_at_[hidden])
Date: 2004-09-02 01:30:48

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.
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.

> 
> > It would be awesome to have a forward iterator approach for the access
> > of integer values, as it would free you from the "chains" of mpl.
> 
> I don't really view MPL as "chains".  Sure, it introduces certain overhead
> (very annoying with VC6, by the way), but, when working with newer and more
> conformant compilers, it behaves nicely and really enables one to remove a
> lot of complexity from the code.  Do you still write your own linked lists
> or do you use ones provided by STL? :)
> 
> > I am all for joining our efforts and creating a single typeof
> > implementation. typeof is even more needed for non-conforming
> > compilers to manage simple tasks as remove_pointer, remove_bounds etc.
> 
> I am not sure about "single typeof implementation".  You may have started
> with some of my code, but by now two implementations look totaly different.
> Since you are not going to adapt my approach (because of limitations of
> VC6), and I am (most likely) not going to adapt yours (because, despite the
> fact that I admire what you were able to achieve with VC6, I still happen to
> like my approach better), there is not much opportunity for code reuse.
> 
> What we probably should do is to keep our "interfaces" in-sync.  This way
> we'll be able to dispatch at the configuration level, in a similar way I am
> doing now with the native typeof.
> 
> How about that?
> 

That was what I was thinking of, yes. Since my method uses a common
compiler bug, it can not be made to work with all the compilers
anyway. Conditional compile is a nice thing :)

The two (or more) emulations of typeof should probably be tested with
different compilers to see which implementation is best suited for
that compiler.

> Regards,
> Arkadiy
> 
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>