[boost] Re: Re: An alternative typeof macro

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2004-09-01 10:36:16

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

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

Regards,
Arkadiy