From: david.brown@hesbynett.no   
      
   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.  (It can be an important operation - such as for software   
   floating point routines.  But the people who write those are few, and   
   they know what they are doing.)   
      
   >   
   > You forgot about the type-punning part, which I guess needs yet another   
   > inlined function,   
      
   I didn't forget about anything.  I didn't write the incorrect C code.   
      
   >   
   >>> Rather more fiddly and error prone, and it needs an auxiliary   
   >>> statement that makes it awkward to embed into an expression. (I also   
   >>> had to think twice about that format code.)   
   >>>   
   >>> BTW here is how my C transpiler translated it, so it /can/ be done   
   >>> without explicit temporaries:   
   >>>   
   >>>   
   >>> mminc$m_print_u64(msysc$m_getdotslice((i64)msysc$m_tp_r64toi64((x +   
   >>> y)),(i64)52,(i64)62),NULL);   
   >>>   
   >>   
   >> Avoiding explicit temporaries is not a goal to aspire to - unless you   
   >> are trying to squeeze performance from a poorly optimising compiler.   
   >   
   > The memory temp involved a declaration which needs to exist outside of   
   > the expression in standard C. While type-punning in C either means   
   > writing to a union, or using & and applying a cast.   
   >   
      
   "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, 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.   
      
   > (My type-punning works on rvalues and will work on values in registers.)   
   >   
   >> No, what was shown was how _BitInt(12) could let people write clearer   
   >> C code than C without _BitInt.  There was no comparison to other   
   >> languages or other features.   
   >   
   > But when it came my example, it could trivially be done with inline   
   > functions, just like this could.   
   >   
      
   Sure.   
      
   >   
   >   
   >>>   
   >>>>> But as a systems language, it is much more enticing than C.   
   >>>>   
   >>>> And that is presumably why it is so much more popular than C.   
   >>>   
   >>> If it was generally available then I think quite a few would prefer it.   
   >>   
   >> Sure.  Keep telling yourself that.   
   >   
   > Well, it would be a minority. Grown-up languages with decent syntax   
   > exist such as Ada and Fortran; those are not that popular. People prefer   
   > brace-based languages such as C, Java, Go, Zig, Rust.   
   >   
   > Anything without braces isn't taken as seriously, eg. scripting languages.   
   >   
      
   What a /very/ strange way to distinguish or classify languages.  And   
   what a bizarre way to generalise what people think, as though all   
   programmers share the same opinions.   
      
   >>   
   >>> As it is I enjoy the benefits myself.   
   >>>   
   >>   
   >> That I /do/ believe - and I genuinely think it is great that you enjoy   
   >> it.   
   >>   
   >   
   > I've had several opportunities to retire my language and switch to C.   
   > Each time, I rejected that and chose to perservere with mine, despite   
   > the extra problems of working with a language used by only one person on   
   > the planet.   
   >   
   > Then, because I genuinely considered it better, and now because I enjoy   
   > working at it and with it. Using C feels like driving a model T.   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)