From: bc@freeuk.com   
      
   On 26/11/2025 20:43, David Brown wrote:   
   > On 26/11/2025 19:42, bart wrote:   
   >> On 26/11/2025 16:37, David Brown wrote:   
   >>> On 26/11/2025 16:44, bart wrote:   
   >>   
   >>> The "other people" I referred to are the folks behind the C language,   
   >>> not me.   
   >>   
   >> OK. The people who chose to make 'break' do two jobs, unfortunately in   
   >> parts of the language that can overlap in use; those people! (I guess   
   >> you mean the more recent lot.)   
   >>   
   >>>> In C, the solution for my example might look like this:   
   >>>>   
   >>>>      double temp = x+y;   
   >>>>      printf("%llu", ((*(uint64_t*)&temp)>>52) & 2047);   
   >>>>   
   >>>   
   >>> No, that's not how a C solution would work.  People who know C would   
   >>> know that.  As a challenge for you, see if you can spot your mistake.   
   >>   
   >> This was my point. (Although I can't see the problem, making it even   
   >> more pertinent.)   
   >>   
   >   
   > So you can claim to have a "better" solution than C, without knowing how   
   > to write it correctly in C?   
      
   >   
   >>>   
   >>> (And of course if anyone wanted to do this stuff in real code, they'd   
   >>> wrap things in a static inline "bit_range_extract" function.)   
   >>   
   >> Also my point: everyone will invent their own incompatible solutions   
   >> for this fundamental stuff.   
   >   
   > It is not remotely fundamental.  Extracting groups of bits from the   
   > representation of a type, especially a floating point type, is a niche   
   > operation.   
      
   A bit like that BitInt(12) example then?   
      
   This is about a lower-level systems language working with primitive   
   machine types, and having access to the underlying bits of those types.   
      
   How much more fundamental can you get?   
      
   C provides only basic bitwise operators, and you have to do some   
   bit-fiddling, while trying to avoid UB, in order to extract or inject   
   individual bits or bitfields.   
      
   I provide direct indexing ops to get or set any bit or bitfield, which   
   is actually a great core feature to have, but for some reason you want   
   to downplay it.   
      
   You might just admit for once that it is quite neat.   
      
      
   >  (It can be an important operation - such as for software   
   > floating point routines.   
      
   That particular task can be important for lots of reasons.   
      
   >  But the people who write those are few, and   
   > they know what they are doing.)   
      
   And I don't? I used to write FP emulation routines...   
      
      
   > "Type punning" refers to using a union to access or reinterpret the   
   > underlying bit representation.  Using references and a cast to do so is   
   > UB,   
      
   In C maybe, using your favoured compilers. In my implementations of C,   
   and in my languages, it is well defined, especially as it is   
   type-punning a 64-bit quantity to another 64-bit quantity.   
      
   (This is a great thing about creating your own implementations: you get   
   to say what is UB, which will be for genuine, not artificial ones   
   maintained so that C compilers can be one-up on each other.   
      
   As it is, somebody using C as an intermediate language can have a   
   situation where something is well-defined in their source language,   
   known to be well-defined on their platforms of interest, but inbetween,   
   C says otherwise.)   
      
   Note that in the original example in my language, no references are used   
   (the code just copies a FP register to a GPR without conversion).   
      
   > except when using pointers to character types.  Neither involves   
   > actually putting data into memory or the stack unless you are using a   
   > compiler that can't optimise well - and then it is just a matter of less   
   > efficient generated code.   
      
   OK, so how would you do a 'reinterpret' cast in C, of a value like 'x+y'?   
      
   >> Anything without braces isn't taken as seriously, eg. scripting   
   >> languages.   
   >>   
   >   
   > What a /very/ strange way to distinguish or classify languages.   
      
   It's an observation. Which languages that call themselves 'systems   
   languages' these days don't use braces?   
      
   >  And   
   > what a bizarre way to generalise what people think, as though all   
   > programmers share the same opinions.   
      
   You're welcome to do your own survey.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)