From: bc@freeuk.com
On 30/11/2025 04:31, Janis Papanagnou wrote:
> On 2025-11-30 03:30:42, bart wrote:
>> On 30/11/2025 00:46, Keith Thompson wrote:
>>> bart writes:
>>>> You can have general _BitInt(N) syntax and have constraints on the
>>>> values of N, not just an upper limit.
>>>
>>> No you can't, because the language does not allow the arbitrary
>>> restrictions you want. If an implementer finds _BitInt(1187)
>>> too difficult, they can set BITINT_MAXWIDTH to 64.
>>>
>>> One more time: Both gcc and llvm/clang have already implemented
>>> bit-precise types, with very large values of BITINT_MAXWIDTH.
>>> What actual problems has this fact caused for you, other than giving
>>> you something to complain about?
>>
>> What problem would there be if BitInt sizes above the machine word
>> sizes had to be multiples of the word sizes?
>
> Not sure whether you're talking at cross-purposes. (I haven't
> followed all postings or details.)
>
> If, on a 64-bit-word system, _BitInt(80) would produce an error
> (because it "had to be multiples of the word sizes", as you say),
> that would obviously be a problem, don't you think?
How did you represent an 80-bit type up to now? How much of a problem
has it actually been?
>> It what way would it inconvenience /you/?
>
> If I couldn't define _BitInt(80) I'd indeed consider that a problem.
> Or any other constant value that stems from my application domain.
Which domain is that, is it representing, as an integer, the 80-bit
float type from an x87 FPU?
>
>>
>> I just don't unlike unnecessarily flexible, lax or over-ambitious
>> features in a language. I think that is as much poor design as
>> underspecifying.
>
> You mean you have problems with, say, "char a[81]" as well?
If the feature was about bit-arrays, then I agree that any arbitrary
size must be meaningful, within broad limits.
But _BitInt(N), especially without the 'unsigned' prefixed that I've
rarely seen used in the examples in this thread, has been heavily pushed
as a numeric type.
Each extra bit doubles the range of values it can represent. The user
cares only that N is sufficient to represent that data, so a few surplus
bits are neither here nor there: the N itself is not critical.
With char[N], there is also char[] which, in the form of 'char*' or
'char(*)[]' with an accompanying N, can be used to create functions that
can work with such arrays of any length.
You can also individually index any individual element (or create a
pointer to any element).
Neither of these possibilities exist for BitInt(N). So it's a feature
that does neither one thing well nor the other.
With char[] also, element 0 is always at the lower memory address. I
don't think endianess has been mentioned for BitInt, so I don't know
where large multi-word BitInts have the least significant word on
big-endian systems.
(BTW my second language has actual bit-arrays and Pascal-style bit-sets.
Both features could be usefully added to a systems language in
fixed-size form, but would have the same capabilities as the char[]
example above, plus more.)
>>
>> So I'm interested in what that one extra bit in a million buys you. Or
>> that one bit fewer.
>
> It's not about extra bits. It's about making it possible to define
> what your tasks (that are to be implemented) ask for. (In my book.
> YMMV.)
Yet over the past decades nobody has been screaming because they
couldn't have a 31-bit or 65-bit numeric type. But now suddenly EVERYONE
wants to be able to do that, and on huge numbers!
I think there's more psychology at play here than anything else.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
