Re: [boost] [mpl] Integral Constant is over specified

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

"David Abrahams" <dave_at_[hidden]> wrote in message 
news:uy7u227q7.fsf_at_boost-consulting.com...
> "Andy Little" <andy_at_[hidden]> writes:
>
>> "David Abrahams" <dave_at_[hidden]> wrote in message
>> news:uy7u32kxw.fsf_at_boost-consulting.com...
>>> "Andy Little" <andy_at_[hidden]> writes:
>>>
>>>> "David Abrahams" <dave_at_[hidden]> wrote in message
>>>> news:upsfhdfsd.fsf_at_boost-consulting.com...
>>>>> "Andy Little" <andy_at_[hidden]> writes:
>>>>>
>>>>>> "Aleksey Gurtovoy" <agurtovoy_at_[hidden]> wrote in message
>>>>>> news:m1k65tgzvi.fsf_at_meta-comm.com...
>>>>>>> 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:

5.3.2-2
5.2.6
5.3.2

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 ;-)

regards
Andy Little