Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk