home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c      Meh, in C you gotta define EVERYTHING      243,242 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 242,115 of 243,242   
   Keith Thompson to bart   
   Re: _BitInt(N)   
   24 Nov 25 16:46:32   
   
   From: Keith.S.Thompson+u@gmail.com   
      
   bart  writes:   
   > On 24/11/2025 13:33, Keith Thompson wrote:   
   >> bart  writes:   
   >   
   >>> What about arrays of _BitInt(1), _BitInt(2) and _BitInt(4)? These   
   >>> could actually be practically implemented, with a few restrictions,   
   >>> and could save a lot of memory.   
   >> No, they couldn't.  Array indexing is defined in terms of pointer   
   >> arithmetic, and you can't have a pointer to something smaller than one   
   >> byte.   
   >   
   > The restrictions I mentioned were to do with pointers to individual bits.   
      
   Right.  C doesn't have pointers to individual bits.   
      
   > It is possible that operations such as:   
   >   
   >    x = A[i]   
   >    A[i] = x   
   >   
   > can be well defined when A is an array of 1/2/4-bit values, even if   
   > expressed like this:   
   >   
   >    *(A + i)   
      
   Not in C as it's currently defined.   
      
   > But this would have to be indivisible when A is such an array: only   
   > the whole thing is valid, not (A + i) by itself, or A by itself; you'd   
   > need &A.   
   >   
   > This would need a small tweak to the language, but that is nothing   
   > compared to supporting (i3783467 * i999 / i3) >> i17.   
      
   It would hardly be a "small tweak".   
      
   I can imagine some future version of C adding support for indexing   
   packed arrays, but I don't think it would have been worthwhile   
   just so that large arrays of small _BitInts can be stored more   
   efficiently.  Doing that on ordinary hardware was not part of the   
   rationale for C23's bit-precise integer types, and I haven't seen   
   any such proposals for C2y.   
      
   And assuming that "(i3783467 * i999 / i3) >> i17" means what I think   
   it means, huge bit-precise integers are already standard (they're   
   part of C23), and the work of implementing them is largely done in   
   gcc and llvm/clang.   
      
   > But I write a script in my dynamic language,   
   [...]   
      
   > C can only get down to that u8 figure (100MB) using its 'char'   
   > type. Even 'bool' doesn't make it smaller (presumably for the reasons   
   > you mentioned).   
   >   
   > You are forced to emulate such arrays in user-code using shifts and masks.   
      
   Yes.  C doesn't support packed arrays, and is unlikely to do so   
   any time in the near future.  C23 added a feature that doesn't do   
   everything you want it to do.  You can of course implement such   
   things in a library, but the syntax for using it would probably be   
   a bit ugly.   
      
   And in fact at least one person has done so.  (I've known about   
   this for about a minute, so I have no comment other than that   
   it exists.)   
      
   https://github.com/gpakosz/PackedArray/   
      
   --   
   Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com   
   void Void(void) { Void(); } /* The recursive call of the void */   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca