Live data from Hacker News

The C Book (HTML Book on C)

phy.duke.edu

11–20 of 23 posts

Re: The C Book (HTML Book on C)

#11
post #10

Awesome timing. I'm just starting to contemplate porting the prototype VM i'm working on to C. Thanks Mahmud! You seem to be coming to the rescue often these days :-p

The book is from 1991, almost 20 years ago. There is a lot of outdated information. You should perhaps look for something more recent, that covers C99 and features commonly found on current compilers.

Thanks for the heads-up. Is C really that different now that I need to worry about it? I have done some work in C++ before, but that was many years ago and I've grown accustomed to high-level languages...

Re: The C Book (HTML Book on C)

#12
post #10

Earlier quoted context omitted.

The book is from 1991, almost 20 years ago. There is a lot of outdated information. You should perhaps look for something more recent, that covers C99 and features commonly found on current compilers.

Thanks for the heads-up. Is C really that different now that I need to worry about it? I have done some work in C++ before, but that was many years ago and I've grown accustomed to high-level languages...

No it's not that different. GCC still compiles 1978 C.

Re: The C Book (HTML Book on C)

#13
A quick question: the book (at least early on) advocates this for main:

    # implied int; implied void
    main() {
        # whatever
        exit(0) # or EXIT_SUCCESS
    }
Is this simply a stylistic choice (rather than a more explicit int main(void) and return(0)). I'm mostly curious, but I know that how to deal with main can be a sacred cow.

Edit: And sure enough clang (by default) and gcc (with -Wall) both issue warnings.

Re: The C Book (HTML Book on C)

#14

A quick question: the book (at least early on) advocates this for main: # implied int; implied void main() { # whatever exit(0) # or EXIT_SUCCESS } Is this simply a stylistic choice (rather than a more explicit int main(void) and return(0) ). I'm mostly curious, but I know that how to deal with main can be a sacred cow. Edit : And sure enough clang (by default) and gcc (with -Wall ) both issue warnings.

The book was written 20 years ago, before the C99 spec was released. main() was acceptable but discouraged in C89, which is why -Wall (or more precisely -Wimplicit-int) displays a warning. It's disallowed by the C99 spec and will always give you a warning.

Re: The C Book (HTML Book on C)

#15

A quick question: the book (at least early on) advocates this for main: # implied int; implied void main() { # whatever exit(0) # or EXIT_SUCCESS } Is this simply a stylistic choice (rather than a more explicit int main(void) and return(0) ). I'm mostly curious, but I know that how to deal with main can be a sacred cow. Edit : And sure enough clang (by default) and gcc (with -Wall ) both issue warnings.

The book was written 20 years ago, before the C99 spec was released. main() was acceptable but discouraged in C89, which is why -Wall (or more precisely -Wimplicit-int) displays a warning. It's disallowed by the C99 spec and will always give you a warning.

[deleted]

Re: The C Book (HTML Book on C)

#16
post #12

Earlier quoted context omitted.

Thanks for the heads-up. Is C really that different now that I need to worry about it? I have done some work in C++ before, but that was many years ago and I've grown accustomed to high-level languages...

No it's not that different. GCC still compiles 1978 C.

Good thing I'm using GCC then! Thanks Mahmud!

Re: The C Book (HTML Book on C)

#17
post #10

Earlier quoted context omitted.

The book is from 1991, almost 20 years ago. There is a lot of outdated information. You should perhaps look for something more recent, that covers C99 and features commonly found on current compilers.

Thanks for the heads-up. Is C really that different now that I need to worry about it? I have done some work in C++ before, but that was many years ago and I've grown accustomed to high-level languages...

In essence, it is the same language, just that it evolved considerably since then. There are places where you could really use a more current reference. For example, the book instructs you to define the main function like:

    main(){
      /* ... */
    }
This is considered bad code style for todays standards. It doesn't state the return value (it defaults to int) and it leaves the argument list open (you can pass any number of arguments to the function).

In other places, it puts restrictions that are no longer relevant today. For example, since C99 (and most compilers allowed this long before C99) you can declare variables anywhere inside a block (which is pretty handy), and not just at the beginning of the function.

Re: The C Book (HTML Book on C)

#18
post #10

Awesome timing. I'm just starting to contemplate porting the prototype VM i'm working on to C. Thanks Mahmud! You seem to be coming to the rescue often these days :-p

The book is from 1991, almost 20 years ago. There is a lot of outdated information. You should perhaps look for something more recent, that covers C99 and features commonly found on current compilers.

I was given this book for my 15th birthday - it rescued me from Sinclair Basic! It may be old but it's a very readable C tutorial and won't lead people far astray.

Re: The C Book (HTML Book on C)

#19
post #10

Earlier quoted context omitted.

The book is from 1991, almost 20 years ago. There is a lot of outdated information. You should perhaps look for something more recent, that covers C99 and features commonly found on current compilers.

Thanks for the heads-up. Is C really that different now that I need to worry about it? I have done some work in C++ before, but that was many years ago and I've grown accustomed to high-level languages...

Its the same, but C99 adds a couple of neat features like boolean types, variable length arrays, variadic macros, inline functions and a lot more.

Re: The C Book (HTML Book on C)

#20
post #7

Earlier quoted context omitted.

Do you have no feelings at all for your fellow man? :(

Misery loves company? More seriously, I take your point. I say that a lot ("Good to know it's not just me."). I'll have to think a little bit more about why .

> I say that a lot ("Good to know it's not just me."). I'll have to think a little bit more about why.

I say it a lot too, especially when talking about interfacing with external resources, and I don't think it's anything to do with enjoying others' misery. It's simply being happy to have it confirmed that the problem you're observing is (probably) someone else's fault, not your own; this carries the bad news that you (probably) can't fix it yourself, but the good news that you don't have to fix it yourself.

Post reply on HN