"Walter Bright" <[email protected]> wrote in message news:[email protected]... > Nick Sabalausky wrote: >> Custom bitfields are extremely useful for low-level code. Being a >> self-proclaimed "systems" language, there's no reason D should consider >> such a thing to be of "narrow-usefulness". > > I've written a lot of low-level code, I even programmed Mattel > Intellivision cartridges and one of those old 70's hand-held LED games > (Mattel Soccer). I've done a lot of embedded 6800 microprocessor work, > device drivers, graphics drivers, etc. I've done a lot of bit twiddling > code. > > But I find C bit fields to be generally worthless. > > One reason is the standard requires them to be right justified after > extraction. This kills performance. I muck with with them in-place using > biased arithmetic.
Actually, with "bitfields", I've been mostly referring to pretty much just that: doing manual bit-twiddling, typically aided by manifest constants and/or enums, and taking the stance that doing that could use a better (ie, more abstracted and more type-safe) interface (while still keeping the same under-the-hood behavior). Maybe it's all the low-level stuff I've done, but any time I come across the term "bitfield" I instinctively envision those abstract rows of labeled "bit" squares (or differently-sized rectangles) that you see in spec sheets for digital hardware (ie, the abstract concept of a small piece of memory having bit-aligned data), rather than specifically the structs-with-sub-byte-member-alignment that I keep forgetting C has. I can't really comment on that latter kind as I've never really used them (can't remember why not), although I can easily believe that they may be insufficient for the job. Maybe that difference is where the disagreement between me and Andrei arose.
