>> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost