:: Re: [DNG] Studying C as told. (For …
Startseite
Nachricht löschen
Nachricht beantworten
Autor: Edward Bartolo
Datum:  
To: dng
Betreff: Re: [DNG] Studying C as told. (For help)
Hi,

Steve Litt 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.
>>


It was a mental struggle but I understood it. Bitwise operations can
be useful in some circumstances. I remember when I was still a youth,
I used to find an irresistible challenge in any examination question
saying, "the proof of this formula is beyond the scope of this exam".
This book will offer its challenges like those 'irresistible formulae'
of my youth, but those challenges, should eventually ripen my C coding
ability.

Steve Litt wrote:
<<
Save your brainpower for pointers to functions. That's actually
massively useful, and extremely difficult.
>>


I assume these are whatDelphi Pascal offers as procedural pointers.
They are an extremely powerful programming feature that gives
polymorphic-like properties to code.

Here is the result of your "temptation":

#include <stdio.h>

int (*fn_ptr)(int a);

int func1(int a) {
return a*a;
}

int func2(int b) {
return b/2;
}

int main() {
fn_ptr = &func1;
printf("12 passed to func1 is: %d\n", fn_ptr(12));

fn_ptr = &func2;
printf("12 passed to func2 is: %d\n", fn_ptr(12));

return 0;
}

Irrwahn wrote:
<<
IMHO the people that (ab)used Dijkstra's famous essay (with
the original title "A Case Against the Goto Statement") as
the foundation of some kind of religion did him and the
programming community as a whole a bad service. For the
interested, David Tribble's "Go To Statement Considered
Harmful: A Retrospective"[4] makes for a good read.
>>


I use goto in one circumstance that helps make code simple to write
and understand. This is when code makes a series of tests with every
test causing the execution flow to jump down to the same point.

The pseudo-code is something like this: [ Note that code is jumping
always down ]

if test1 ready goto A;
if test2 ready goto A;
if test3 ready goto A;
...
if testN ready goto A;

more code here
Lable A:

execution continues from here

This can still be done by something like this:
do {
if (test1) break;
if (test2) break;
if (test3) break;
...
if (testN) break;

more code here
} while (0);

execution continues from here


Edward