On Wed, 1 Sep 2004 11:36:16 -0400, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
"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.
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