"big" integer constants
Ed Smith-Rowland
3dw4rd@verizon.net
Sat Oct 29 04:55:00 GMT 2011
On 10/28/2011 09:53 PM, DJ Delorie wrote:
>> To be honest, I suspect much more than this doesn't work on 16 bit
>> targets, but sure in principle we can change that. Let's ask Ed if he is
>> willing to spend again time on this old work of him... (imho, all those
>> hard coded iteration numbers don't really look right in the first place,
>> just imho)
> Yeah, normally I would just say "don't use those" but in this case,
> gcc is giving an ICE for each of those, since it can't convert the
> integer to a suitable constant.
>
> I suspect there's still something in my port that needs work, but
> those seemed like arbitrary numbers anyway ;-)
>
We could definitely change that limit to 65535U or maybe
std::numeric_limits<unsigned short>::max() or something. Is
sizeof(short) == sizeof(int) consistently on 16 bit targets? If so I'd
go for the latter.
These magic numbers exist in gsl and other libraries but the
hypergeometric functions are especially bad about this. That's why they
were dropped from TR29123 (which passed by the way).
I'm actually working on TR29123 hopefully to get in before stage1 ends.
All it really does is add the special math functions to std:: (minus the
hypergeometric functions which were regarded as too flaky for
standardization). Basically it does some moving of files and some other
bits.
Ed
More information about the Libstdc++
mailing list