On Tue, 14 Sep 2004 09:31:59 -0400, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
"Peder Holt" <peder.holt@gmail.com> wrote
<vertleyb@hotmail.com> wrote:
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&);
Could you explain this in more detail? I am pretty uncomfortable with the whole idea of compile-time variables... As far as I understand now, to set them, the compiler needs to instantiate the template which contains the code that sets the variable, something like this:
template<> struct encode { SET(compile_var); };
If encode is reused (not instantiated), the variable is not set.
I believe I raised this question some time ago, and you said you added an additional parameter to force the instantiation... How then it can be reused?
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.
I actually don't think they are VERY similar. We would write more code trying to fit them together, then both of them already have. This is a matter of taste, of course, but I am against reuse in such cases. This would just put more fog on things that are not that easy to understand in the first place.
I don't agree. Consider the following code: #ifdef BOOST_NO_PARTIAL_TEMPLATE_SPECIALIZATION #define DECODE_TYPE_IMPL_BEGIN(name,Iter)\ template<>\ struct decode_type_impl<CONST_ID>{\ template<typename Iter>\ struct decoder { #define DECODE_TYPE_IMPL_END() };}; #define DECODE_TYPE(Iter)\ typename decode_impl<Iter::value>::decoder<BOOST_DEDUCED_TYPENAME Iter::next> #else #define DEDOCE_TYPE_IMPL_BEGIN(name,Iter)\ template<typename Iter> struct decode_type_impl<mpl::int_<name>,Iter>{ #define DECODE_TYPE_IMPL_END() }; #define DECODE_TYPE(Iter) decode_type<Iter> #end This would allow us to create a unified decode implementation: DECODE_TYPE_IMPL_BEGIN(CONST_ID) typedef DECODE_TYPE(Iter) d1; typedef typename d1::type const type; typedef typename d1::iter iter; DECODE_TYPE_IMPL_END() DECODE_TYPE_IMPL_BEGIN(PTR_ID) typedef DECODE_TYPE(Iter) d1; typedef typename d1::type* type; typedef typename d1::iter iter; DECODE_TYPE_IMPL_END() I think this is at least worth consideration. -- Peder Holt
Regards, Arkadiy
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost