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. 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
> 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.
That is probably as close as you will get ...
bool x = false;
bool y = x | bool(1);
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
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
> 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 ;-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk