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,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk