
On Mon, 13 Sep 2004 17:19:33 -0400, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
Hi, again. I have done some more tinkering with the compile time constant typeof emulation. It now compiles for VC 6.5,VC 7.0 and GCC 3.4 I have split the one argument constant into two. One per typeof instance, and one to iterate (from 1 to N) down the "type tree". This method also improves on the previous in that when a type T has been deduced using BOOST_TYPEOF, the type is reused when BOOST_TYPEOF is used again.
How could it not be? Templates only have one point of instantiation for any given set of arguments.
With my previous implementation, the next available compile time constant was included in the encoding and decoding structs, forcing new instantiations to be created for every typeof This has now been fixed.
Anyhow, I have also implemented a feature for improving on the 64 template depth restriction. Haven't got access to an EDG based compiler, but the implementation worked fine with VC 6.5
I have also looked at the newes implementation of your integral encoding, Arkadiy, and it is basically the same as I am doing. I use one value to encode an integer, with the exception of 0xffffffff and 0xfffffffe, but the side effect is that I can not use arrays to create a size for sizeof. I have to use a struct containing two arrays, and I don't know if this is as portable, so I should perhaps adapt to your way of doing it.
Also, your version of TYPEOF_REGISTER_TEMPLATE_X differs from mine. Where I use TYPEOF_REGISTER_TEMPLATE(some_class,2,(typename,unsigned int)), you use TYPEOF_REGISTER_TEMPLATE_X(some_class,(typename)(unsigned int))
My has the advantage of looking more like a template argument list. Your has the advantage of not having to specify the number of template arguments...
Which one is best?
I haven't had time to do any work on integrating the two solutions yet, my typeof implementation is not mature enough, I guess, as I haven't tested it against any other unfortunate compilers without partial template specialization support. Help on this would be greatly appreciated.
Sounds like integration instead of a big #ifdef switch might be appropriate now (?)
The parts that can be reused, are: - much of the scheme for registering templates with integral constants - All the decoding stuff (with different iterators) The difference in encoding is basically that of iterators as well, My input to the encode struct is 2 integers (which are incremented at each step) Arkadiys input to the encode struct is a vector of integers. But I agree, the difference between encoding is rather large, and it may be more confusing than not to make a single implementation of it. -- Peder Holt
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost