[boost] Re: Re: Re: Re: Boost MPL problem

From: Jaap Suter (J.Suter_at_[hidden])
Date: 2003-03-23 14:31:31

>> I've done it somewhat differently in the new code.
>
> Eh, whoops; your template invokes num_bits_set_impl, which isn't
> defined.  Also, next is spelled "netxt". I also think you may have a
> problem with eager evaluation or one too many ::type s.  I think you
> should test these.

Woops. I just woke up, read your message and changed it right away. Sounds
like a case of "get some coffee before you code".

The quality of the Effective MPL (especially after the new MPL changes) is
not very good anyway. I would like to make a major overhaul, testing all
code examples, changing the code layout (moving it to docbook perhaps), and
making it 1.30.0 MPL conformant), but I won't have any time for at least
another three weeks. If somebody wants to beat me to it (Dirk?) great, but
otherwise it'll have to wait.

>>> I also think it would be a great idea to have "zero" and "one"
>>> metafunctions (which also satisfy the integral constant wrapper
>>> requirements) If we wanted to get funky we could make it so
>>> zero<int_<3> > and zero<long> both work.
>>
>> Those would be greatly appreciated, and very useful.
>
> Care to submit some files?  This seems like a super-easy job.

Sure thing. Done by next friday.

> but all of these ideas feel conceptually pretty hairy
> to me.  Remember that the integral sequences are conceptually just
> convenient front-ends for regular type sequences.

Yes, I tend to forget this because I never use type-lists directly, I only
have a use for lists of compile-time constants at the moment.
I ran into this exact same thing when I was trying to implement an mpl::set
sequence. It worked fine for lists of constants. Types, however, aren't
sortable, so it becomes really hard to implement for generic type sequences.

One could implement a set that does not 'duplicate' values, but the
following is harder because insertion order matters:

    typedef mpl::set< float, int, bool > set_0;
    typedef mpl::set< bool, int, float, > set_1;

    mpl::is_equal< set_0, set_1 >::type // Mmmmm, hard.

I guess we could specialize algorithms for sets, but that defeats the
purpose of having an iterator abstraction, etc.

Oh well, I'm probably just overlooking something.

> I understand the need you have, but I am really unsure of the best
> way to address it.

Well, I guess taking the value_type of the front isn't that bad then.

Thanks for your help,

Jaap Suter