"Peder Holt" <peder.holt@gmail.com> wrote
On 5/28/05, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
This workaround is much better than mine because it doesn't degrade vc8 preformance. And it might be better than the original (before workaround) solution in terms of portability -- other compilers might have the same problem vc8 has. One thing -- we might consider a function template instead of preprocessor-generated values...
Not quite sure how that should work.
instead of: char (&value0)[...]; char (&value1)[...]; char (&value2)[...]; ... char (&value50)[...]; just have: template<int n> char (&value(mpl::int_<n>))[...]; But now I am thinkig this may re-introduce the original performance problem...
One more thing, I also tried modifying boost::type_of::vector a bit:
struct vector_base { char (&value0)[1]; char (&value1)[1]; char (&value2)[1]; ... char (&value50)[1]; };
template<typename T=void> struct vector0 : vector_base { }
template<typename P0,typename T=void> struct vector1 : vector_base { char (&value0)[T0::value]; }
... template<typename P0,..typename P49,typename T=void> struct vector50 : vector_base { ... };
template<class T> typename encode_type<vector0<>,T>::type typeof_result(const T&);
This seems to make a ~20% improvement on the VC compilers at least (haven't tried GCC on this change yet)
Cool. I originally thought that type_of::vector<> is just a temporary workaround, until mpl::vector<> performance problem with GCC is fixed, but now I am not so sure... It was already about 20% performance improvement over mpl::vector<> on VC7 (because operations were specialized directly rather than their implementations, which resulted in fewer template instantiations). Now even better performance... I think the Typeof library is intended to be very low-level, and as such, deserves a fine-tuned custom compile-time sequence with no overhead that can't be avoided by a generic solution. The current implementation allows to easily switch from one type of such a sequence to another, which simplifies performance testing, and which may turn out useful if different sequences turn out to be the best for different compilers. I do think that we should keep the interface of the mpl::vector<>. Again, something to think about after the review. Regards, Arkadiy