"David Abrahams" <dave@boost-consulting.com> wrote in message news:uy7u227q7.fsf@boost-consulting.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uy7u32kxw.fsf@boost-consulting.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:upsfhdfsd.fsf@boost-consulting.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote in message news:m1k65tgzvi.fsf@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