Boost logo

Boost :

From: Andy Little (andy_at_[hidden])
Date: 2006-08-06 07:51:01

"David Abrahams" <dave_at_[hidden]> wrote in message
> "Andy Little" <andy_at_[hidden]> writes:
>> "David Abrahams" <dave_at_[hidden]> wrote in message
>>> "Andy Little" <andy_at_[hidden]> writes:
>>>> "David Abrahams" <dave_at_[hidden]> wrote in message
>>>>> "Andy Little" <andy_at_[hidden]> writes:
>>>>>> "Aleksey Gurtovoy" <agurtovoy_at_[hidden]> wrote in message
>>>>>>> Andy Little writes:
>>>>>>>> In my use of integral constants, comparison for equality is the most
>>>>>>>> used operation, followed by arithmetic. I have never used the next
>>>>>>>> ,prior functions. To me math ,comparison and logic operations are
>>>>>>>> more likely candidates for Integral Constant Requirements.
>>>>>>> IMO they are too heavy-weight. I understand your desire to have a
>>>>>>> concept encompassing these, but so far I don't see a compelling reason
>>>>>>> why Integral Constant should be such a concept (and I find it somewhat
>>>>>>> amusing that the title of this thread is "Integral Constant is over
>>>>>>> specified" :).
>>>>> Aleksey's point here is that you are now advocating *more*
>>>>> specification, which contradicts your subject line.
>>>> Nope.
>>> Yep.
>> Nope. I am still advocating removing the next prior requirements, hence the
>> title of the thread.
> This is getting silly. Are you, or are you not, advocating adding a
> bunch of other requirements (math ,comparison and logic operations) to
> the concept as well?

Nope. I am still advocating removing the next prior requirements, hence the
title of the thread.

>>>> Having next prior as requirements but not the usual operations on
>>>> integers strikes me as odd.
>>> Yes, but that's not necessarily a good criterion for determining what
>>> should be a concept.
>> mpl::bool_ is stated to be a model of mpl::IntegralConstant, but
>> exercising the requirements on it results in a failure to
>> compile. Maybe the mismatch is acceptable to you, but I don't find
>> it satisfactory.
> It isn't satisfactory. Look, we've been through this before; there
> are lots of ways to deal with that problem. Clearly the requirements
> need a small adjustment to handle boundary cases anyway, because
> exercising the requirements on int_<INT_MAX> results in undefined
> behavior, which by induction means int_<X> is not an IntegralConstant
> either. Maybe bool_<true> needs next and bool_<false> needs prior
> also.
> Until
> bool x = false;
> bool y = x + bool(1);
> becomes illegal I'm not going to agree that next/prior is a defect in
> IntegralConstant, and if it did become illegal I might just say we
> need a new concept for bool.

I found a useful reference in the C++ standard. Annex D D.1.

Also see:


That is probably as close as you will get ...

Anyway FWIW

bool x = false;
bool y = x | bool(1);

is superior:

int main()
    bool x = false;
    bool y = x + bool(1);
    bool y1 = x | bool(1);

// asm unoptimised in VC8
; 6 : bool x = false;

 mov BYTE PTR _x$[ebp], 0

; 7 : bool y = x + bool(1);

 movzx eax, BYTE PTR _x$[ebp]
 add eax, 1
 setne cl
 mov BYTE PTR _y$[ebp], cl

; 8 : bool y1 = x | bool(1);

 movzx edx, BYTE PTR _x$[ebp]
 or edx, 1
 mov BYTE PTR _y1$[ebp], dl

; 9 :

> If you want to say IntegralConstant
> could be more intuitively (or even better) defined, great. But your
> approach is to assert that next/prior are definitively wrong is just
> off-putting, because I know it's not as black-and-white as you seem to
> assert.
> If you have run into an actual problem, please describe it and how it
> has come up in your work, and we can try to look for an appropriate
> solution. Changing concept requirements is a serious documentation-
> and code-breaking change, and I wouldn't do it just because the
> concept seems odd to you.

The IntegralConstant requirements have just been changed. Now you have to do:

 typedef boost::mpl::integral_c_tag tag;

How do I make my Integral Constants compatible with mpl ,
boost::integral_constant and std::integral_constant ?

that's my main problem. Anyway I'm working on it ;-)

Andy Little

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