Boost logo

Boost :

From: Jaap Suter (J.Suter_at_[hidden])
Date: 2003-01-01 23:47:47


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< 0 >,
                mpl::int_c< 3 >

has a different type than this one:

        mpl::int_c< 0 >,
        mpl::int_c< 3 >

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

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.


And now on to the good stuff...

If you go to you will find a file called
''. In it are four files called:


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
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,


Jaap Suter

Boost list run by bdawes at, gregod at, cpdaniel at, john at