From: david.brown@hesbynett.no
On 01/12/2025 12:29, bart wrote:
> On 01/12/2025 10:33, David Brown wrote:
>> On 30/11/2025 18:55, bart wrote:
>>> On 30/11/2025 17:17, Janis Papanagnou wrote:
>>>> On 2025-11-30 13:51:22, bart wrote:
>>
>>
>>
>>>
>>> I've said many times that it's a poorly designed feature.
>>
>> You have said continuously that you think everything about C, along
>> with everything you believe to be related to C (however tenuous the
>> connection may be in reality) is poorly designed.
>
> With C it is 75% about syntax. Some of it is about type systems, but
> mostly it is similar to what I have. The new _BitInt (which as you know
> I don't much like) makes the divergence greater.
>
So your argument against C is that it is different from your language.
That's /very/ persuasive.
>
> It seems that
>> absolutely everything that you did not design personally, is poorly
>> designed in your eyes. I'm not even sure you think your own languages
>> are well designed, given the number of times you've found new features
>> or limitations that you didn't know they had.
>
> Yeah, I'm a bit of a perfectionist. So what?
You are taking your highly subjective and personal views on "perfect"
and applying them mindlessly to something different made by many people,
for the use of many people. And worst of all, you believe that your
opinions are somehow objective - you assume that anyone who says they
like, or even merely don't object to, a particular feature of C is
either lying or mistaken.
We all know that C is not "perfect", no matter how "perfect" might be
defined - because we all know that is completely impossible.
You are not a perfectionist. You are a negativist. I am fully
convinced that if you had not invented the languages you use, but were
presented with them by someone else, you would moan and groan about them
as much as you do about C.
>
>> Perhaps you just have a different scale of what is "poor design" and
>> "good design". Or maybe you don't understand that things don't have
>> to be perfect to be good enough in practice.
>
> And my own designs are also full of compromises. One big one is that the
> systems language knows its place; I keep it simple and don't try and
> make it one or two levels higher. Other modern 'systems' language are
> much higher level, but also harder to use, more complicated, and less
> efficient to process.
>
>> You certainly don't seem to understand that when there is more than
>> one person involved - and for C, there are millions involved -
>> compromises are inevitable, and elegance of design must bow to
>> compatibility requirements.
>>
>>> Read the thread, as I'm not going to repeat things.
>
>>
>> Is that a promise?
>
> How a look at the first post I made in the thread. I've no idea how to
> do links, so a copy of it is pasted below.
I had a look - it's whining and moaning about how terrible _BitInt is,
despite not having a clue about what it is, why it was introduced, how
it could be implemented and how people might use it.
>
> My other posts are mostly defending that view.
Your other posts are repeating most of the same stuff - either
specifically about _BitInt, or generally about C.
>
>
>> The answer, it seems, is that many people do think they can use
>> _BitInt to make their code better in some way. It doesn't matter if
>> one person thinks _BitInt(128) will be useful, while another thinks
>> _BitInt(12) is something they'd use.
>
> How much of this feature came about because of LLVM's support for
> integer types up to 2**23 or 2**24 /bits/? I thought /that/ was crass.
The feature did not come about because of that.
>
>> It doesn't matter if they will use them for FPGA programming,
>> small-systems embedded programming, cryptography, neater bitfield
>> structs, or whatever. And most importantly, it does not matter in the
>> slightest if someone does /not/ want to use a particular size of _BitInt.
>
> That's like saying we should all be using C++ compilers for C programs,
> and just ignore all the features we don't want.
Do you bother to read posts at all? I didn't say anything that could
plausibly be interpreted in any such manner. It is very difficult to
communicate with someone who does not seem to be willing or able to
understand the written word.
All programmers of all languages will, for the most part, ignore
features they don't want.
And people should obviously use C++, or any other language, instead of C
if it suits their needs better - why would anyone not use the most
suitable language (where "suitable" is all-encompassing, including
developer knowledge, tool and target support, task requirements, and
anything else you can think of) ?
>
> So why /do/ C-only compilers still exist?
>
> =============================================================================
>
> bart:
> On 23/11/2025 13:32, Waldek Hebisch wrote:
> > Philipp Klaus Krause wrote:
> >> Am 22.10.25 um 14:45 schrieb Thiago Adams:
> >>>
> >>>
> >>> Is anyone using or planning to use this new C23 feature?
> >>> What could be the motivation?
> >>>
> >>>
> >>
> >> Saving memory by using the smallest multiple-of-8 N that will do.
> >
> > IIUC nothing in the standard says that it is smallest multiple-of-8.
> > Using gcc-15.1 on AMD-64 is get 'sizeof(_BitInt(22))' equal to 4,
> > while the number cound fit in 3 bytes.
>
> The rationale mentions a use-case where there is a custom processor that
> might actually have a 22-bit hardware types.
>
Yes, that is one possible use-case. It is neither necessary nor
sufficient, but is one example.
> Implementing such odd-size types on regular 8/16/32/64-bit hardware is
> full of problems if you want to do it without padding (in order to get
> the savings). On even with padding (to get the desired overflow semantics).
>
No, it is quite straightforward when you know _BitInt's are specified.
(And note that the final definitions in the standard are /not/ a direct
copy of everything mentioned in the proposal.)
> Such as working out how pointers to them will work.
>
There are no problems there. You should know that by now.
>
> >> Also
> >> being able to use bit-fields wider than int.
> >
> > For me main gain is reasonably standard syntax for integers bigger
> > that 64 bits.
>
> Standard syntax I guess would be something like int128_t and int256_t.
> Such wider integers tend to be powers of two.
>
If C23 were only adding a 128-bit type, then I'd agree that int128_t and
uint128_t would be the best names. (There are would be certain details
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
