"Peder Holt" <peder.holt@gmail.com> 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