On 26 July 2016 at 14:31, Warren D Smith wrote: > 1. Gcc with stdint.h already > provides such nice predefined types as uint8_t. > Sizes provided are 8,16,32, and 64. > In some sense uint1_t is available too (stdbool.h) > but at least on my machine stdbool uses 8-bits to store a bool,
Because that's the smallest addressable unit. > e.g. an array of 1000 bools takes 8000 bits, > which is asinine and kind of defeats the point. If you want 1000 boolean values then don't use 1000 bool variables, do something like std::bitset or std::vector<bool> in C++, i.e. create an array of some integer type and write functions for accessing individual bits. > I suggest adding uint1_t, uint2_t and uint4_t support > to gcc, and packed. You can't have a variable of a single bit, because you can't address it. You can have smaller-than-a-byte variables as bitfields inside structs, but you don't need a typedef for that. > 128 would be nice too. GCC already supports __int128 and __uint128 where possible. > It is obnoxious and arbitrary that only 8,16,32,64 are available, It's obviously not arbitrary, it's dictated by the hardware. > and it is a pain to make programmers continually > have to reinvent the wheel to implement packed nybbles, etc -- > and even when I do so, then my implementation results in ugly > code, different than the nice-looking code for packed bytes. > Why not allow me to write uniform code? Why not catch up > to freaking PASCAL from 40 years ago, which already > provided packed arrays? This ought to be pretty trivial given > that you already did 8,16,32,64 to do 1,2,4 also. Patches welcome. > 2. Gcc already provides a way to produce quotient and remainder > simultaneously, producing a struct with two fields as output: > div_t x = div(a,b); causes x.quot = a/b, x.rem = a%b. > Not a lot of people know gcc provides that, but it does, and that is > good, because > it provides access to the hardware capability. GCC doesn't provide that, the C library does, because it's defined by standard C and has been for decades.
