Hi,
I've written some MPL meta-functions that might be useful. But first a
question though...
Is it possible that (under certain conditions) the following line:
mpl::int_c<
mpl::minus<
mpl::int_c< 0 >,
mpl::int_c< 3 >
>::type::value
>
has a different type than this one:
mpl::minus<
mpl::int_c< 0 >,
mpl::int_c< 3 >
>::type
I thought that the MPL propagates types cleanly, but in some rare cases I
need to wrap the result in a simple type to get things to compile.
Unfortunately, I haven't been able to reproduce this behaviour in a simple
case. It only shows up in fairly complicated code, which I can't reproduce
here.
FYI, I'm using the Intel compiler. If you have any ideas or suggestions, let
me know and I will put some more effort in trying to find the smallest
example that exhibits this behaviour.
Thanks.
And now on to the good stuff...
If you go to http://jaap.flipcode.com/boost/ you will find a file called
'bit.zip'. In it are four files called:
bit_and.hpp
bit_or.hpp
bit_xor.hpp
bit_shift_right.hpp
I am using all of these in my own code currently, and they work fine there.
Considering it's mostly copy paste work from the other meta-functions, it
shouldn't present any difficulties. I didn't need the bit_shift_left meta
function, so I haven't written that one yet. Once discussions has settled,
I'll be glad to add that one too.
Open issues:
1. I don't like the 'bit_' prefix, but there are already logical 'and' and
'or' operators and corresponding files. One option is to use 'bitwise'
instead, but I liked the shortness of 'bit'.
2, On my PC I've placed these files in the boost/mpl/bit directory, just
like boost/mpl/arithmetic and boost/mpl/logical have their own directories.
Obviously, once dust has settled we need to make a 'bit.hpp' that includes
all the bit_* files, and place it in the MPL root.
3. The bit_xor and bit_or functions are really simple. The bit_and function
however
presented a problem for the default values of parameters 3 to 5. I'm using
0xFFFFFFFF right now, which happens to work on my (32 bit) platform, but
obviously this is not a good solution. Any suggestions are welcome.
4. The interface for the bit_shift_right (and left) function should be
decided. Right now, the bit_shift_right_c function takes two types, and two
constants. However, I am not very knowledgable on what operator >> and <<
are allowed to do according to the standard (For example, can the righthand
operand be negative, when is a logical, bitwise or arithmetic shift
performed, what if the lefthand operand is negative, etc. etc.). The
bit_shift_right (non _c) function just takes two parameters as usual, and
using AUX_TYPEOF their types are passed to the bit_shift_right_c function
(as with all the other meta-functions).
Comments are welcome,
Cheers,
Jaap Suter
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
