On Sat, 15 Jun 2024 16:16:14 +0200 Mattias Andrée <maand...@kth.se> wrote:
> You will save between 0 and 3 bytes on common platforms, > and those 3− bytes will probably be allocated and wasted anyway. > Is it worth it? > > It's absolutely better than _Bool, but I don't think there > is any point in using char over int. All common operations > (this may exclude division and modulo) supported on int, > by definition, that same is not true for char. Say for example > that, want to check if the value is non-zero. Using it, this > will probably entail performing some operation on the value > and than duing a jump conditioned on a flag register. With > more narrow types, this may (not the case on x86-64) require The x86-64 instruction set doesn't require type promotion, but the CPU may still require it, and although I'm not certain, I think x86-64 CPU does perform type promotion in these cases. It should at least be fair to say that less complex CPU will do this to avoid implementing all different operations for all the different type, and CPU's may also avoid it and instead favour type promotion in order to improve parallellism. > that value to first be promoted to int. > > > On Sat, 15 Jun 2024 17:05:27 +0300 > stefan11111 <stefan11111@shitposting.expert> wrote: > > > What about using char's then? > > > > În 15 iunie 2024 15:36:16 EEST, "Mattias Andrée" <maand...@kth.se> a scris: > > > > >I have some general issues with _Bool: > > > > > >Arithmetic or bitwise operations on _Bool is subject to type promotion > > >making them rather pointless. > > > > > >With also be a problem if they were not, as you than couldn't sum of > > >_Bool's > > >to find how many were set (commonly this we be to detect if more than 1 was > > >set). > > > > > >It is implementation-define which signness _Bool has, meaning, I don't know > > >if it will be promoted to a signed or an unsigned int. > > > > > >_Bool is only useful to make sure that a non-zero value is converted to the > > >value 1. And if this is absolutely necessarily, you should make this > > >explicit, > > >e.g. with `!!x` or `x?1:0`. _Bool can introduce implicit and unnecessary > > >overhead to ensure that the value is always 1 or 0. And despite all this, > > >you can mess up and get _Bool's with a non-boolean value. > > > > > >It is implementation-defined how wide a _Bool is. > > > > > >_Bool will be at least the size of a byte, if you really want it to be a > > >bit > > >if you have many of them, you can use bit fields or good old names values > > >to > > >store multiple boolean values in one int. Generally you don't gain any real > > >savings by using a single byte type instead of an int if you only one or > > >two > > >booleans. > > > > > >Basically, I like things to be explicit and well-defined. > > > > > > > > > > > >On Sat, 15 Jun 2024 11:54:02 +0000 > > >Zac <mac...@protonmail.com> wrote: > > > > > >> In a number of spots in dwm and st I've seen the use of integers as > > >> booleans. e.g. > > >> - dwm.c line 95, 140, 1870 > > >> - drw.c line 252 > > >> - st.c line 44, 48 > > >> > > >> That's not an extensive list; just some examples. > > >> > > >> I'm curious why you use ints though. Because bools are 31 bits smaller > > >> than ints, which is 31 bits of memory saved. Not that 31 bits is very > > >> much, but still... > > >> > > > > > > > > > >
