On Fri, 24 Jun 2016 09:19:40 +0200
Edward Bartolo <edbarx@???> wrote:

> Bitwise Operators:
>
> Pg 63:
> /* getbits: get n bits from position p */
>

> unigned int getbits(unsigned int x, int p, int n)
> {
>    return (x >> (p + 1 - n)) & ~(~0 << n);
> }

Stuff like this is the reason I soon abandoned K&R as a learning tool,
and used it only to determine the official behavior of C.

Bit stuffing, sliding and masking were a tool of the assembly programmer
back when your RAM could be counted in four digits and your processor
had little power. Using x, p and n instead of container_int,
bit_position and bits_to_consider was relevant when computers were so
anemic that shorter variable names made for faster compiles. And also,
long variable names are difficult to format in a print book.

In this day and age (and as a matter of fact since the early 1990's),
packing bits into ints is usually premature optimization. It's usually
better to malloc() 1024 ints whose values will be either 0 or 1 than
to malloc() 64 its whose values go from 0 to 65535, and access
individual bits. If RAM or performance later becomes an issue, THAT'S
the time to bit-stuff and bit-manipulate.

When K&R originally wrote their book in 1978, there were plenty of
computers running magnetic core memory, and the language of system
programmers was assembler. And early C didn't optimize that well. So of
course they wrote their C with assembler idioms.

I'd personally de-prioritize the bit arithmetic stuff. You can learn it
at any time. The other thing I'd de-prioritize is the question mark
operator: It's just (sometimes confusing) shorthand for what
if/else if/else can do.

Save your brainpower for pointers to functions. That's actually
massively useful, and extremely difficult.

SteveT

Steve Litt
June 2016 featured book: Troubleshooting: Why Bother?
http://www.troubleshooters.com/twb