Re: [boost] Re: Re: typeof

From: Peder Holt (peder.holt_at_[hidden])
Date: 2004-09-14 05:56:10

On Tue, 14 Sep 2004 06:04:12 -0400, Arkadiy Vertleyb
<vertleyb_at_[hidden]> wrote:
> "Peder Holt" <peder.holt_at_[hidden]> 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
>