On Tue, 14 Sep 2004 06:04:12 -0400, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
"Peder Holt" <peder.holt@gmail.com> wrote
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.
What I totaly don't understand is how you can get the compiler reuse templates, and still set the compile-time variables. As far as I understand, setting a compile-time variable is a side-effect of a template instantiation, which IMO contradicts the reuse...
Earlier, I created a function with a return value that instantiated a compile time constant. encode_type<T,NEXT_INDEX()> start(const T&); On VC 6.5, anyway, this caused TYPEOF to be reinstantiated, but VC 6.5 isn't the most conforming compiler on the market, so this may have been another of its bugs :)
The parts that can be reused, are: - much of the scheme for registering templates with integral constants
I agree here.
- All the decoding stuff (with different iterators)
Are you going to make an MPL sequence from compile time variables?
My implementation of decoding: template<> struct decode_impl<CONST_ID> { template<typename Iter> struct decoder { typedef typename decode_impl<Iter::value>::decoder<BOOST_DEDUCED_TYPENAME Iter::next> next_decoder; typedef typename next_decoder::type const type; typedef typename next_decoder::end end; }; }; Your implementation of decode: template<class Iter> struct decode_type_impl<mpl::int_<CONST_ID>, Iter> { typedef decode_type<Iter> d1; typedef const typename d1::type type; typedef typename d1::iter iter; }; Where template<class Iter> struct decode_type : decode_type_impl<typename mpl::deref<Iter>::type, typename mpl::next<Iter>::type> {}; As far as I can see, these implementation are very similar. All that is needed is to either implement the proper mpl traits for my compile time constants iterator, or create a common abstraction for the next and deref<Iter> (value, in my implementation)
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.
We would most likely end up with, instead one big #ifdef switch, a dozen #ifdef switches in every file...
Agree. I'll take a look at it anyway. -- Peder Holt
Regards, Arkadiy
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost