Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

If C == C then wouldn't C++ == C + 1?

By miah in Technology
Tue Feb 20, 2001 at 04:08:52 PM EST
Tags: Help! (Ask Kuro5hin) (all tags)
Help! (Ask Kuro5hin)

As a sys admin and Perl/PHP programmer I enjoy Linux as a stable kernel to use as a development environment and all around operating system. But I now find myself wanting to do some system programming in C. I am looking for a few good books/links to further my learning of C in a *NIX envirionment.

Being a big fan of O'Reilly as a publisher I thought that I would go back to the old standby and check them out first. So I purchased Practical C Programming and burned through this text in an afternoon or two. But now I find myself almost clueless as to where I go now for information regarding programming under my favorite operating system (for I am still a novice C programmer). What can the readership recommend for the next purchase of a book on C?

My other lament comes from the fact that there (to my knowledge) is no existance of a website pertaining to programming in C under linux that could be called relative to sites such as Perl Monks on the Perl side or PHP Builder on the PHP side.

If anyone has any suggestions, please reply and make yourself heard.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Best ways to learn C
o Plagarism is the sincerest form of profit 15%
o Have Morpheus download it in 28%
o Smash face against the stack 22%
o Why C, when assembler is so easy? 33%

Votes: 104
Results | Other Polls

Related Links
o Perl
o Linux
o O'Reilly
o Practical C Programming
o Perl Monks
o PHP Builder
o Also by miah

Display: Sort:
If C == C then wouldn't C++ == C + 1? | 71 comments (65 topical, 6 editorial, 0 hidden)
Yes... (3.00 / 4) (#1)
by Sairon on Thu Feb 15, 2001 at 12:38:39 AM EST

I'm pretty decent at some C stuff, myself, and am trying to learn to program for both Windows and *nix. Finding good sites for C and C++ ARE hard. Books, though... are many... Maybe if you'd like we could start one from our experiences?


usenet (3.50 / 2) (#12)
by pallex on Thu Feb 15, 2001 at 05:04:21 AM EST

Look at comp.lang.c and comp.lang.c.moderated. sure people there can point you at good books/sites.
People will warn you to avoid anything by Schildt! You`ll want to get a book that covers Ansi C.

[ Parent ]
Schildt. (3.33 / 3) (#39)
by TransientReflection on Fri Feb 16, 2001 at 09:56:54 AM EST

Yes, stay away from Schildt if you want to <b>learn</b> C or C++.

The thing that annoys me about people's attitude toward him though, is that most of his books clearly state "reference" in the title, and are O.K. as such - as an alphabetical reference to C and C++ standard libraries. There is the occasional typo, but there are few things that are just plain wrong, and when they are wrong they're usually just out of date, and fixed in the next edition.

So, no, don't learn C or C++ from Schildt - but his books that are billed as "references" are O.K., but not perfect, if you use them as the author titled them - "references", and don't go using his (definitely weak) intro sections on the language as the basis for learning how to program.

[ Parent ]
Too inaccurate to be a good "reference". (4.00 / 1) (#40)
by seebs on Fri Feb 16, 2001 at 10:13:59 AM EST

Sorry, but the errors are just too widespread. His books are great references to some language, but that language ain't C.

[ Parent ]
Well, at least it ain't ANSI/ISO C (4.00 / 1) (#47)
by joto on Fri Feb 16, 2001 at 12:08:01 PM EST

I think I read a most hilarious review of one of his books somewhere. It was "The annotated ANSI C reference" or something like that. The book had a page of the ANSI standard on one side, and Schildt's comments on the other page. Even then, Schildt managed to mess up several places. Sometimes his code-examples contradicted the standard displayed at the opposite page! And some places he even managed to get the standard text wrong.

[ Parent ]
well... (4.22 / 9) (#2)
by xriso on Thu Feb 15, 2001 at 12:49:39 AM EST

The Unix Programming FAQ is all about the more advanced topics of programming C in UNIX. As an introduction to basic IO, you might want to try this 'Net C tutorial.

Generally, C is closely tied to UNIX, and generally, Linux acts a lot like UNIX. You don't need to know any Linux-specific stuff most of the time.

Anyway, I hope you have fun in the lovely world of pointers and printf :-). You might have a bit of a challenge adapting to the lowlevelness of C, after working with Perl.
*** Quits: xriso:#kuro5hin (Forever)

oops, I forgot to add this: (3.72 / 11) (#3)
by xriso on Thu Feb 15, 2001 at 01:01:03 AM EST

About that title:

Saying C++ == C + 1 is technically unpredictable. There is no order of evaluation in C in a situation like this, so anything can happen. The compiler is allowed to make any code it wants.

But, with a reasonable compiler, if this is evaluated left-to-right:

  C++ -> returns C, then increments
  C + 1 -> returns the recently incremented value of C, plus 1
  So, it's like saying C == C + 2, which is false.
If it's evaluated right-to-left (some compilers do this!):

  C + 1 -> returns C + 1
  C++ -> returns C, then increments
  So, it's like saying C == C + 1, which is also false.
So, on a reasonable compiler, C++ == C + 1 will always be false.
*** Quits: xriso:#kuro5hin (Forever)

Associativity (3.00 / 1) (#9)
by squigly on Thu Feb 15, 2001 at 03:20:49 AM EST

Are you wure about that. K&R says that the == operator is evaluated from left to right. I remember a rant by Brian Kernighan about Pascal he complained that Pascal didn't do this. It would be an odd complaint if the C spec said that it was allowed to.

People who sig other people have nothing intelligent to say for themselves - anonimouse
[ Parent ]
Boo-boo (4.00 / 2) (#11)
by pw201 on Thu Feb 15, 2001 at 05:03:19 AM EST

Associativity is not the same as order of evaluation (associativity governs how an expression is parsed). The order in which operands are evaluated is not specified by the ISO standard except for &&, ||, ?: and the comma operator (Kernighan's rant talks about the short circuiting logical operators). It is not safe to assume what a reasonable compiler will do.

If you want to know more, read Les Hatton's book (or better yet, get him to come and talk to you, if you're in the UK: he's a great speaker. What I've written above is from the course notes). To get back on topic, it's not a book for people who don't already know C reasonably well, and some parts are just lots of tables and stats, but it is interesting. C Traps and Pitfalls is the standard book of C gotchas, which I must read at some point!

[ Parent ]

C++==C+1 (2.33 / 3) (#14)
by wiredog on Thu Feb 15, 2001 at 08:30:13 AM EST

Is, of course, how C++ got its name.

The idea of a global village is wrong, it's more like a gazillion pub bars.
[ Parent ]

The successor to C (3.00 / 1) (#29)
by gbd on Thu Feb 15, 2001 at 05:07:17 PM EST

Actually, the language that succeeds C should have been called P.

Bonus points if you can explain why this is.

Gunter glieben glauchen globen.
[ Parent ]

BCPL (3.00 / 2) (#38)
by TransientReflection on Fri Feb 16, 2001 at 09:35:04 AM EST

Because of BCPL, which was C's ancestor. - B to C to P to L

I remember BCPL, because the amiga's original 1.x DOS were written in it - meaning that until later releases of the AmigaOS, you had to be aware of wierdness when calling using the dos.library shared library.

The original AmigaDOS was based on Cambridge TriPOS. It didn't hang perfectly with the rest of the OS, which was written in C and m68k assembler.

The TriPOS port was a last-minute thing, when the orignal DOS, called CAOS, was not completed in time. for information on CAOS and the Amiga-that-might-have-been, check out this article

[ Parent ]
The name encourages bad usage (3.66 / 3) (#46)
by PhilHibbs on Fri Feb 16, 2001 at 12:06:55 PM EST

In C or C++, the expression "C++" means "Increment the variable C, but use the prior value", so in this context, it means "Improve the language, but carry on using all the old features". It should, therefore, be calles "++C".

[ Parent ]
Improving languages (4.75 / 4) (#51)
by Khalad on Sat Feb 17, 2001 at 04:33:15 AM EST

It's not so much a problem nowadays, but for the longest time most so-called C++ programmers didn't know much about the features outside of the C subset. Perhaps the name was supposed to reflect the actual usage of the language...

C++ is a beast. It takes a long time to master C++ in any reasonable sense of the word: once you grasp classes, you have to understand encapsulation; function overloading is cute, and operator overloading is so neat that you immediately abuse it in unexpected ways; after you learn about inheritance you can't figure out if your private members should be protected or not; and after inheritance is polymorphism, which most people simply avoid because of the miniscule performance hit; the abomination that is multiple inheritance will blow your mind somewhere along the way, and you probably won't ever feel very comfortable with it; then generic programming—templates—comes along with syntax out of every programmer's worst nightmares (God knows what B.S. was thinking!); and finally there are exceptions. And after you learn all of these concepts, and you feel comfortable with the cryptic syntax, and you finally feel like you've mastered C++, you say to yourself, "Fuck this!" and download Eiffel.


And oh, how beautiful and readable it is, and how nice it is to know that after all the hard work of the last 30 years in language design it takes only 40 lines of code to implement a counter class.

  description: "Counters that you can increment by one,
  decrement, and increment"


feature -- Access

  item: INTEGER     -- Counter's value.

feature -- Element change

  increment is      -- Increase counter by one.
      item := item + 1
      item = old item + 1

  decrement is      -- Decrease counter by one.
      item > 0
      item := item - 1
      item = old item - 1

  reset is          -- Reset counter to zero.
      item := 0
      item = 0

    item >= 0

But, you know... the old ways really aren't so bad. Classes, inheritance, function overloading, polymorphism, templates, exceptions, constraints... The old war-horse

int counter;
is looking pretty darn good right about now.

You remind me why I still, deep in my bitter crusty broken heart, love K5. —rusty

[ Parent ]
This is funny as hell. (5.00 / 3) (#55)
by i on Sun Feb 18, 2001 at 01:18:58 PM EST

But, in all fairness, you forgot to add at least

#define DECREMENT_COUNTER(x) (--x, assert(x>=0))
You may also want to add
typedef int counter_t;
#define INCREMENT_COUNTER(x) (++x, assert(x>=0))
#define RESET_COUNTER(x) (x = 0)
#define GET_COUNTER(x) (x)
#define DECLARE_COUNTER(x) counter_t x = 0
because your program is not multithreaded yet. And then, when your program finally becomes multithreaded and you have transformed your macros to
typedef struct {int counter; pthread_mutex_t mutex;} counter_t;
#define INCREMENT_COUNTER(x) (pthread_mutex_lock(&x.mutex), \
  ++x.counter, assert(x>=0), pthread_mutex_unlock(&x.mutex))
#define DECREMENT_COUNTER(x) (pthread_mutex_lock(&x.mutex), \
  --x.counter, assert(x.counter>=0), pthread_mutex_unlock(&x.mutex))
#define RESET_COUNTER(x) (pthread_mutex_lock(&x.mutex), \
  x.counter = 0, pthread_mutex_unlock(&x.mutex))
#define GET_COUNTER(x) (x.counter)
everything goes Ok... until you discover that mutex operations do allocate memory and you have to call pthread_mutex_destroy when you no longer need a counter... ok, turned every stone adding calls to FINISH_WITH_DARN_COUNTER(x)... oh my, integer operations are not atomic and I have to lock on read as well... hmm, how do I do that with a macro in C?

Then you say "Fuck this!" and download...

and we have a contradicton according to our assumptions and the factor theorem

[ Parent ]
you download... (none / 0) (#66)
by xriso on Wed Feb 21, 2001 at 06:39:28 PM EST

Lisp! Everybody knows lisp is perfect. :)
*** Quits: xriso:#kuro5hin (Forever)
[ Parent ]
Re: The name encourages bad usage (4.00 / 1) (#52)
by Shampoo369 on Sat Feb 17, 2001 at 04:44:22 AM EST

"Increment the variable C, but use the prior value", so in this context, it means "Improve the language, but carry on using all the old features".
Just curious... Is this a joke or not? I thought it was pretty funny, thus the 5, but I'm interested to know if you intended it to be funny or were just being a bit overanalytical.


"If you really want something in this life, you have to work for it -- Now quiet, they're about to announce the lottery numbers!"

[ Parent ]
Nineteen Eighty-Four (none / 0) (#68)
by nickwkg on Thu Feb 22, 2001 at 11:25:24 AM EST

C++ also, of course, refers to George Orwell's Nineteen Eighty-Four. Newspeak consisted of 3 languages, A B and C. A was designed for everday use, B for political and C for technical. Double plus (++) was used in this way:

"The food was double plus good."

C++ is therefore the technical language, but more so.

[ Parent ]
postfix increment happens AFTER expression (3.50 / 4) (#21)
by Speare on Thu Feb 15, 2001 at 11:21:04 AM EST

C++ -> returns C, then increments
C + 1 -> returns the recently incremented value of C, plus 1

Yep, but I had to check the ARM on this. The only defined behavior is that the operand be incremented after the value is noted. I had assumed that the increments happened after ALL the dust settled at the end of the expression.

    ; Line 8: d = (c++ == c + 1);
    mov eax, DWORD PTR _c
    add eax, 1
    mov ecx, DWORD PTR _c
    mov edx, DWORD PTR _c
    add edx, 1
    mov DWORD PTR _c, edx
    cmp ecx, eax

From Visual C6's default settings, it shows the compiler evaluating right to left: building (c+1) in eax, then keeping a (c) in ecx, then performing (c++) in edx, then using the original (c) in ecx for comparison.

[ e d @ h a l l e y . c c ]
[ Parent ]
<sigh> You're missing the point (3.00 / 3) (#34)
by psychonaut on Thu Feb 15, 2001 at 09:22:02 PM EST

From Visual C6's default settings, it shows the compiler evaluating right to left: building (c+1) in eax, then keeping a (c) in ecx, then performing (c++) in edx, then using the original (c) in ecx for comparison.

Since when does Microsoft dictate the C standard?

What is or is not allowable in a language, and what is or is not correct behaviour, is not determined by the people who write the compiler. It is determined by the creators of the language and the standard that follows (where one exists). The ANSI standard for C says that any expression that modifies and references the same variable within the same sequence point produces undefined behaviour. This effectively means (according to the standard) that the compiler is free to emit any code it chooses. Just because Visual C++ produced the assembly code you posted does not mean a) that any other compiler will produce functionally equivalent code, and b) that Visual C++ will produce the same code on any subsequent compilation. (True, having a compiler perform nondeterministic behaviour is undesirable, but the point is that the standard does not preclude it from doing so when dealing with undefined expressions.)

Therefore, unless you have access to the source code of your compiler to verify that it is processing your undefined statement deterministically, and you do not plan on ever compiling the program containing this undefined statement with any other compiler (nor any other version of the same compiler), you simply cannot rely on said program to behave consistently and in an expected manner.

Moral of the story: never use statements which invoke undefined behaviour.

[ Parent ]
ahem. (2.50 / 2) (#35)
by xriso on Thu Feb 15, 2001 at 09:28:48 PM EST

Yes, you're absolutely right. I was pondering telling him the same thing, but it kinda looked like a troll or flamebait to me.

BTW: Just because you disagree with peoples' comments, why do you rate them a 1?
*** Quits: xriso:#kuro5hin (Forever)
[ Parent ]

Moderation (4.00 / 2) (#36)
by psychonaut on Thu Feb 15, 2001 at 09:47:08 PM EST

Just because you disagree with peoples' comments, why do you rate them a 1?

I don't rate them low because I don't agree with them; I rate them low because they're factually incorrect. Someone who doesn't get their facts straight before posting a bunch of groundless drivel (however well-intentioned) doesn't deserve a 5. (I believe this is in keeping with the moderation scheme as given in the K5 FAQ.) Such posts simply spread confusion and fallacies. On the other hand, opinions to which I am diametrically opposed may well get +5 by virtue of being well-written and well-researched.

[ Parent ]
what was "factually wrong" here? (4.00 / 2) (#41)
by Speare on Fri Feb 16, 2001 at 10:23:02 AM EST

Since when does Microsoft dictate the C standard?

While Microsoft doesn't dictate anything, they've had compiler engineering members on the ANSI committees ever since someone thought K&R needed a little refresher. It gives them an equal chance to raise issues with the standard and to write compilers that comply with the consensus standard of the committee.

There are many other seasoned compiler experts who make up the whole ANSI committee, so don't go off on some anti-Microsoft bender about how they must be distorting all kinds of rules or making their evil plots. Borland likely had members on ANSI, and I'm sure several ANSI members contribute to gcc, Watcom, Ming and other quality C++ compilers.

It is determined by the creators of the language and the standard that follows (where one exists).

I repeat, "I had to check the ARM on this. The only defined behavior is that the operand be incremented after the value is noted." For the uninitiated, the ARM stands for The Annotated C++ Reference Manual by Ellis and Stroustrup. Last time I checked, Bjarne Stroustrup is widely credited as the prime writer and designer of C++'s original and ongoing standards. The book is the ANSI base document: what ANSI states as standard is drawn, usually verbatim, from this book.

I only used a Microsoft /Fa assembler output because I happened to be on a machine with a Microsoft compiler on it. The fact that the Microsoft compiler's behavior complies 100% with the ARM's stated defined behavior for a C++ compiler in this case shouldn't rankle you: it's good for compilers to comply with standards. Microsoft's compiler may not comply in other areas, and surely gcc, Borland, Ming, Watcom and others have their flaws too, or there wouldn't be a need for constant revisions.

Lastly, you moderated my posting to 1, then stated that you did so because of factual errors. I don't care what you rate me, or my posts, but I'd like you to tell me what specifically is factually wrong in my post. I stated that I thought it worked differently. I stated I looked it up. I gave a literal excerpt from cl test.c /Fa test.asm. I remarked that the behavior in one compiler matches the ARM.

[ e d @ h a l l e y . c c ]
[ Parent ]
Bjarne Stroustrup != ANSI (5.00 / 1) (#48)
by psychonaut on Fri Feb 16, 2001 at 01:16:35 PM EST

For the purposes of this message, read "ANSI" as "ANSI/ISO" except where distinguished.

While Microsoft doesn't dictate anything, they've had compiler engineering members on the ANSI committees ever since someone thought K&R needed a little refresher. It gives them an equal chance to raise issues with the standard and to write compilers that comply with the consensus standard of the committee.

True, but this is no guarantee that their compilers will conform to the standard. The lack of for-scoped variables in VC++ 6.0 is a notorious example. To its credit, Microsoft offers a /Za option to force strict ANSI compliance (including for-scoping), but this renders the compiler useless for writing Windows code. On the other hand, many other compilers I've used, such as gcc, stay as true as possible to the C and C++ standards; forcing strict ANSI compliance will only disable extra features, not change something fundamental about the language.

Last time I checked, Bjarne Stroustrup is widely credited as the prime writer and designer of C++'s original and ongoing standards. The book is the ANSI base document: what ANSI states as standard is drawn, usually verbatim, from this book.

Irrelevant. ANSI, not Bjarne Stroustrup, defines ANSI C++. Anything Stroustrup writes about C++ outside of his official capacity on the ANSI C++ committee cannot be taken as any official proclamation on standard C++. Likewise, the C standard may have drawn heavily from K&R, but that's no excuse to consider K&R to be canonical. In fact, K&R C obviously differs on several points from the various incarnations of ANSI C.

Now, onto the factual error you were asking about. You didn't mention until your most recent message that you were talking about C++, so I had presumed you were discussing C. But read on:

The only defined behavior is that the operand be incremented after the value is noted.

I don't have a copy of the C++ standard handy, but I find this highly suspect. I know for a fact that in C the expression is completely undefined, as the standards (ANSI X3.159-1989, and ISO 9899:1990 Sec. 6.3) explicitly state that once one part of an expression becomes undefined, all aspects of it are undefined, including behaviour which might otherwise be expected. So your statement is certainly false as far as C goes. Now, since C++ is largely compliant with C++, there is no good reason why the C++ standard should differ from the C standard on this issue. While I admit that it is possible, I won't believe it until I see a supporting reference from the C++ standard.

[ Parent ]
Order of evaluation in C-like languages (3.00 / 2) (#59)
by pw201 on Tue Feb 20, 2001 at 08:53:30 AM EST

Now, onto the factual error you were asking about. You didn't mention until your most recent message that you were talking about C++, so I had presumed you were discussing C.

When talking about this problem with C-like languages, Prof Hatton told us that Java has a completely defined order of evaluation, but didn't mention C++. It may be that it's partially defined in C++ and that the expression given is defined, but like you, I'm sceptical. It's certainly undefined in C.

[ Parent ]

WRONG -- RTFS (read the fine standard) (4.57 / 7) (#32)
by psychonaut on Thu Feb 15, 2001 at 09:07:00 PM EST

But, with a reasonable compiler, if this is evaluated left-to-right:
So, on a reasonable compiler, C++ == C + 1 will always be false.

And exactly who decides what constitutes a "reasonable" compiler?

The ANSI standard is quite clear when it says that referencing an expression which is modified elsewhere in the same expression results in undefined behaviour. Thus a reasonable compiler is free to produce whatever code it wishes, including returning true, returning false, aborting execution, or playing the Moonlight Sonata while showing a QuickTime movie of Natalie Portman shoving hot grits down your pants. (Yes, the ANSI standard is quite clear in saying that it does not preclude such behaviour.) It is dangerous to assume anything about an undefined statement — what code is produced by one compiler may well be different from code produced with another compiler. Not only that, but what code is produced by two separate compilations of the same program with the same compiler may differ. The only reasonable thing to do is not invoke undefined behaviour in the first place.

[ Parent ]
yes, you're right (3.00 / 1) (#33)
by xriso on Thu Feb 15, 2001 at 09:21:41 PM EST

And that's exactly what I said: "so anything can happen"

I meant to say that if it were only an ambiguity in order-of-evaluation, then it would always be false anyway.

I suppose I could have just said "As the great committee spake in the almighty C Standard, chapter 42, verse 16, all such abominations are OF THE DEVIL!", but I wanted to prove it wrong by logic and not legalism.
*** Quits: xriso:#kuro5hin (Forever)
[ Parent ]

Undefinedness (3.00 / 1) (#54)
by ksandstr on Sun Feb 18, 2001 at 11:01:05 AM EST

The compiler may also cause demons to come flying out of your nose. Thus the expression "nasal demon attack", meaning an undefined condition.

[ Parent ]
You sir, have caused me undue agony. (4.00 / 4) (#4)
by Johnath on Thu Feb 15, 2001 at 01:10:37 AM EST

I am right now in the process of setting up a site which aims to answer exactly this kind of question. It's aim is to be the source for each subject's definitive works - naturally it's user-contributed since I make no claim to know what the definitive book on cell biology is, for example.

The reason you have caused me such pain is that right now I am in the process of getting hosting sorted out for it (since my puny p75 linux box on an @home connect could not support this kind of traffic). The site actually exists, and is fully useable - I was even going to dedicate a diary entry to it to get some early traffic, maybe even add a story to the queue, once there was a modicum of content already there (there are currently only about 30 books added). This is really the Nth story recently of the form "What is/are The Book(s) on topic X" and it kills me that I can't mention the site yet for fear of toasting my little server. :)

At any rate, I apologise if this is a little offtopic, but it just goes to show you that a void exists which I hope the site will fill. Anyone who is interested may email me for the url info, I'd love beta testers - but methinks even k5 has gotten big enough that a mention might inundate me. To yank me back on topic, I will say that, depending on the urgency or your need for it, I may have a whole slew of good books for you, if only you can wait a while, until the site picks up. :)

PS - The site, which is currently being test-hosted on two different, wonderfully generous servers, oughta be up in the next week - whenever school slackens enough that I can sort out config bugs and otherwise breathe life back into it.

Your little box... (3.00 / 1) (#8)
by delmoi on Thu Feb 15, 2001 at 03:03:09 AM EST

Well, actualy your p70 can probably hack it. after all it takes what, a 386 to saturate a t1 with apache? of course, it would flood your cablemodem line....
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
Problem is, it's database driven (3.50 / 2) (#22)
by slaytanic killer on Thu Feb 15, 2001 at 11:25:30 AM EST

Just looked at it (yes, those hits are me). Impressed; I jaunted over to the mathematics section thinking, "These guys certainly won't have Spivak's Calculus." So I'm the dumbass.

[ Parent ]
Right. And Spivak Rocks. (3.00 / 1) (#24)
by Johnath on Thu Feb 15, 2001 at 12:20:13 PM EST

Right, it's the DB that would kill my po' lil' p75, more than the net connect (though a slashdotting would still happily saturate my connect, and probably get @home to drop me too. :)

Heh - yes, we have Spivak's calculus, how could we miss the book dedicated to yellow pig? But also keep in mind that the site is still quite in its infancy, so I am hoping that failures to have certain books on hand is more a reflection of lack of users than failure of site. :) If you have books you wanna add though, by all means, toss em on there.

[ Parent ]

Bookmarks... (3.83 / 6) (#6)
by fremen on Thu Feb 15, 2001 at 01:40:34 AM EST

I knew there was a reason I kept saving this bookmark, despite the fact that I hardly ever program. Have a look at the various C programming FAQs. They're all archived on the web, and you can find them here:


In the Learning C FAQ, it recommends several online tutorials and books for learning C. All the FAQs are good reading, especially the actual C FAQ itself.

Good luck!

Assuming a desert island (4.75 / 12) (#7)
by eLuddite on Thu Feb 15, 2001 at 02:55:48 AM EST

"Advanced Programming in the UNIX Environment" by W. Richard Stevens is worth hundreds of dollars more than its purchase price.

Dont lend it to anyone, you'll just end up having to buy another copy.

God hates human rights.

I Absolutely Agree (4.00 / 1) (#10)
by Tim C on Thu Feb 15, 2001 at 04:47:15 AM EST

That book has to be one of the best texts I have ever read.

Clear, concise, and with good examples, it is indeed worth several times the asking price; I cannot recommend it highly enough.

If you want to know how to write C code in a Unix/Posix environment, buy this book. It's as simple as that.



[ Parent ]
When I read this book.... (4.00 / 3) (#18)
by daystar on Thu Feb 15, 2001 at 10:52:21 AM EST

... I couldn't beleive that no one had recommended it to me. It's the best book investment out there, after the K&R C book.

Really. This book is the line between knowing C and knowing what to do with it.

There is no God, and I am his prophet.
[ Parent ]

Why C++ and not C += 1 (3.60 / 5) (#15)
by Anonymous 242 on Thu Feb 15, 2001 at 09:09:49 AM EST

The ++ operator in C technically means the "next iteration." In number arithmatic, the next iteration is 1 (or 1.0). In pointer arithmatic, the next iteration is the next memory location (which varies according to the size of the type of the pointer in question).

Not to mention that in C++, the ++ operator can be overloaded and the most idiomatic use is to give the next iteration that makes the best sense in context. The next iteration of a vector pointer is different than the next iteration of an element of a linked list.

IIRC, the moniker C++ came about only after something of a political snafu developed with people referring to the "old C" and "new C".

The origin of C++ (4.40 / 5) (#17)
by dabadab on Thu Feb 15, 2001 at 10:37:25 AM EST

[ Disclaimer: it may not be entirely true, but it's the populary known version ]
Once upon a time, there was a language, BCPL (1969).
Ken Thompson (a well known figure from the Bell Labs) was insired by it to create B (where, according to common belief, B comes from the first letter of BCPL, though FOLDOC (Free Online Dictionary of Computing) states that it is not true)).
Dennis Ritchie (also a mythical figure from Bell Labs) was inspired by B, when created his language, that he called C.
Now, there was some uncertainty about whether C comes as the next letter of the alphabet or the next letter from BCPL, and Ritchie did nothing to dismiss it.
So, when Stroustrup created the next language in the line, everyone was eager to know if it will be D or P. But Stroustrup decided not to give away the solution, so he came up with 'C++'
So, my liege, that's how we know the Earth to be banana shaped... er, I mean, that's the myth of the origin of C++'s name.
I think that this story excellently illustrates that CS people have more time on their hands than they should be allowed, so they tend to do utterly useless things (like telling stories like that ;)
Real life is overrated.
[ Parent ]
Not quite... (4.00 / 2) (#28)
by FriedLinguini on Thu Feb 15, 2001 at 04:21:32 PM EST

From Bjarne Stroustrup's FAQ:

For the first few years, I called my language ``C with Classes.'' However people had taken to calling C with Classes ``new C,'' and then C. This abbreviation led to C being called ``plain C,'' ``straight C,'' and ``old C.'' The last name, in particular, was considered insulting, so common courtesy and a desire to avoid confusion led me to look for a new name. I picked C++ because it was short, had nice interpretations, and wasn't of the form ``adjective C.'' In C, ++ can, depending on context, be read as ``next,'' ``successor,'' or ``increment,'' though it is always pronounced ``plus plus.'' The name C++ and its runner up ++C are fertile sources for jokes and puns - almost all of which were known and appreciated before the name was chosen. The name C++ was suggested by Rick Mascitti. It was first used in December of 1983.

[ Parent ]

Not quite correct (4.50 / 2) (#49)
by trhurler on Fri Feb 16, 2001 at 01:54:54 PM EST

If "sizeof(foo*) == 4" and "foo *bar = 8" and you were to print out the value of "bar + 1" you would indeed get 12. That's how ALL pointer arithmetic is done in C, regardless of whether you use the ++/-- increment and decrement operators. The ++ and -- are literally the same thing as writing "+ 1" and "- 1", and are merely a notational convenience. Try it sometime:)

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Preincrement and postincrement (++) (5.00 / 1) (#62)
by Broco on Tue Feb 20, 2001 at 07:22:15 PM EST

I'd have to say not quite. Though it's true that ++ (and --, which works much the same way) is used most often in for loops at the end of every iteration, it's a very general operator which can be used in all sorts of situations.

A (sometimes) important subtlety is that there are actually 2 ++ operators, known respectively as preincrement and postincrement. Most of the time, they work the same way, but there are certain cases in which they differ.

Preincrement is the easier one, so I'll start with that. It is used by placing the ++ before the variable name, just like every other unary operator (*, &, !, etc). The preincrement operator is exactly equivalent to adding one using the assignment and addition operators in C, and almost always in C++. In other words,


in any context, including the middle of a more complex expression, is perfectly equivalent to

x = x + 1

So, this means that in the following sample code, y will be equal to 2, and z to 3:

int x = 1, y, z;
y = (++x); // y = 2, x = 2
z = (x = x + 1); // z = 3, x = 3

In other words, preincrement is just a convenient shorthand. The only exception is in C++, in rare situations involving operator overloading, but it's not worth worrying about.

However, the more common postincrement operator has one additional subtlety: it works mostly the same way, but the variable will only be incremented once the evaluation of the expression is finished. Concretely, this means that in our sample code, y will be equal to 1:

int x = 1, y, z;
y = (x++); // y = 1, x = 2
z = (x = x + 1); // z = 3, x = 3

First, the value of x is assigned to y, and only then is x incremented.

BTW, using postincrement rather than preincrement in the name "C++" has interesting/funny implications. The value of C will only increase once you have finished using it, and have switched entirely to a C++ programming style :).

(sorry for any errors I might have made; I know that whenever I try to describe some programming concept, I always make a few silly mistakes)

Klingon function calls do not have "parameters" - they have "arguments" - and they ALWAYS WIN THEM.
[ Parent ]

LAD (3.00 / 2) (#16)
by enterfornone on Thu Feb 15, 2001 at 10:17:46 AM EST

Linux Application Development by Michael Johnson and Erik Troan is a good look at the low level Linux stuff, signal, terminals, networking etc. (you won't find any GUI programming in there). Not sure how current it is, my copy is dated 98.

comp.* newsgroups are probably the best place to ask stuff like this, although I haven't checked them for a while they weren't looking as bad as alt.* the last time I looked.

efn 26/m/syd
Will sponsor new accounts for porn.
My Copy (none / 0) (#61)
by Matrix on Tue Feb 20, 2001 at 05:33:31 PM EST

I second this - even though the book is out of date (it seems to apply to 2.0.x kernels), much of the information in it is still good. The only major things that have changed for most of the stuff I've looked at so far are what header files delcarations get put in. At the time of the book's writing, it seems like everything was in unistd.h. (I didn't program extensively for Linux then, so I wouldn't have any personal experience.) Now a lot of things seem to be distributed to more specific headers - errno in errno.h, etc.

"...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
- Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
[ Parent ]

Linux Programming sites are out there... (3.66 / 3) (#20)
by slambo on Thu Feb 15, 2001 at 11:19:49 AM EST

Check out http://www.linuxprogramming.com/ for a start, especially the SourceLib link at the bottom of the page.
Sean Lamb
"A day without laughter is a day wasted." -- Groucho Marx
K&R (3.00 / 2) (#23)
by wonderslug on Thu Feb 15, 2001 at 12:03:22 PM EST

Interesting that no one has mentioned _The C Programming Language_ by Kernighan and Ritchie. Hey, they wrote the language. It's a very thin book, but it packs just about everything I've ever needed into it. The other one I've found useful is _A Book on C_. I forget the author.
Change the country in my email to its initials if you want messages to get to me.
Re: K&R (3.00 / 1) (#25)
by kagaku_ninja on Thu Feb 15, 2001 at 02:00:48 PM EST

Aye, laddie. K&R is all you need. Bought my copy 20 years ago, and still have it...

Back then, we only had 7 character identifiers, and we were damn glad too! Kids these days...

[ Parent ]
Please, no... (3.00 / 1) (#26)
by weirdling on Thu Feb 15, 2001 at 03:06:56 PM EST

Don't let another K&R trained C programmer loose on the world.
Seriously, few compilers will correctly parse K&R C anymore, although I did like programming in it, which is a little like not wearing underwear.

I'm not doing this again; last time no one believed it.
[ Parent ]
K & R C (4.25 / 4) (#30)
by Wonka! on Thu Feb 15, 2001 at 05:34:04 PM EST

Actually, the second edition of K&R describes ANSI standard C, not the obsolete "K&R" style C from the first edition.
It's actually one of the better tutorial style books on writing idiomatic C code

-- look out honey 'cuz I'm usin' technology
[ Parent ]
Ira Pohl (3.00 / 1) (#45)
by joto on Fri Feb 16, 2001 at 12:00:05 PM EST

The author's name is Ira Pohl if I remember correctly. It was the first book I ever read on programming, and it is definitely among the best books on C.

[ Parent ]
Yick ... (none / 0) (#67)
by aphrael on Thu Feb 22, 2001 at 04:48:19 AM EST

unfortunately, the guy can't teach; everyone I know who took a class from him at ucsc whined about him incessantly.

[ Parent ]
Two books for effective system programming on UNIX (4.25 / 4) (#27)
by GusherJizmac on Thu Feb 15, 2001 at 04:11:33 PM EST

The first, as many have mentioned, is "The C Programming Language" by Kernighan and Ritche. The second is called "Advanced Unix Programming" by Marc Rochkind.

The third thing to know is that you can man most system calls for c. Try 'man gets'. The first screenful shows you what you need to #include and the prototype of that function and many related functions.

"The C Programming Language" (or "The Old Testament") is really good for learning C and some of the common libraries. "Advanced UNIX Programming" is specific to UNIX and has lots of examples from simple things like file manipulation to complex things like shared memory, pipes and fifos.
<sig> G u s h e r J i z m a c </sig>
Uh, please... (4.33 / 3) (#43)
by joto on Fri Feb 16, 2001 at 11:54:27 AM EST

"The C Programming Language" (or "The Old Testament") is really good for learning C and some of the common libraries.

Perhaps, but there have been an ANSI standard for C for quite some time you know. You would be seriously stupid if you you really are suggesting the old testament (K&R edition 1) as opposed to the new testament (K&R edition 2) which describes ANSI C.

"Advanced Programming in the Unix environment" by Stevens is also quite old, but I don't know of anything better... I am not sure if you messed up the title, or if you are suggesting some other book.

[ Parent ]

A good Reference Book (3.33 / 3) (#31)
by Wonka! on Thu Feb 15, 2001 at 05:48:20 PM EST

I highly recommend C: A Reference Manual by Samuel P. Harbison and Guy L. Steele. It's a very nice, readable reference manual for the ANSI standard C language including ISO C Ammendment 1.
Saves me almost daily, since I can never seem to remember which order the arguments to strcpy go.

-- look out honey 'cuz I'm usin' technology
I second that recommendation... (3.00 / 1) (#44)
by joto on Fri Feb 16, 2001 at 11:57:50 AM EST

The book really is invaluable. One of the nicest things in this book is the discussions of portability betweem ISO C, K&R C and C++ without becoming to entangled with standard issues (which apply mostly to compiler writers). Now with C9x out the door, maybe we could get a new edition?

[ Parent ]
Well, just look better, then... (4.00 / 3) (#42)
by joto on Fri Feb 16, 2001 at 11:45:19 AM EST



ACCU Book reviews (4.00 / 1) (#56)
by codemonkey_uk on Mon Feb 19, 2001 at 05:51:35 AM EST

The Association of C & C++ Users has an execlent book reviews section. You probably want something from each of the following sections:

"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
O'Reilly book on C (3.50 / 2) (#57)
by fuzzrock on Mon Feb 19, 2001 at 09:21:25 PM EST

I didn't see anyone else who mentioned this, so... If what you really want to do is system programming, then I am pleased to recommend O'Reilly's book on that very topic, which is somewhat confusingly titled: "UNIX Systems Programming for SVR4".

It's a bit dated, and not focused on Linux, but it's well written, and filled with crunchy examples. I've been pleased with it.


REQ: Further Help (3.00 / 2) (#58)
by Devil Ducky on Tue Feb 20, 2001 at 01:05:19 AM EST

I was so happy to see this story hit the queue.

I have looked through all of the wonderful suggestions already made, even noting that I own/have used many of them. :)

What I was wondering about was how to do some more "advanced" things. Such as, building system libraries (correctly), modular designing, accessing said libraries, etc.

Does anyone know of a good reference for this level of *NIX programming?

I was starting to think I would have to learn it all the hard way and write a howto... of course I may still have to.

Devil Ducky

Immune to the Forces of Duct Tape
Day trading at it's Funnest
Shared libraries (3.50 / 2) (#64)
by pig bodine on Wed Feb 21, 2001 at 03:40:40 AM EST

By system libraries, I assume you mean shared libraries, ie. '.so' files. Building these is dead simple:

  1. Create a '.c' file containing the functions you want to put in a library (pretty obvious first step). Don't forget to put prototypes for the functions in a '.h' file you will be #including in your programs.
  2. Compile this source using the -fPIC option. (ie. "gcc -c -fPIC foo.c") PIC means "Position Indendent Code"
  3. Link using the -shared option. The ".so" filename must start with "lib" (ie. "gcc -shared -o libfoo.so foo.o")
  4. Put the ".h" file in your /usr/include directory, and the .so file in your /usr/lib directory. Don't forget to set permissions.
  5. When writing programs, #include <foo.h>
  6. When linking programs use "-lfoo" to link to your shared object. (ie. "gcc -o test test.o -lfoo").

This is enough to get a normal shared object working. If you are working on a library that will be used by more than a few people, you'll probably want to include version information. To do this, you send options to the linker using the -Wl compiler option, like this: "gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 foo.o" The commas will be converted into spaces when passed to the linker. The -soname option is used by the linker to set the library's internal name. Note that it has only one version number, but the filename has two. The major version should only change when the library's interface changes. When you place this in your /usr/lib directory, you'll need to create a symbolic link to the library from "libfoo.so" The upshot of this is that programs linked with older version numbers will still work, as long as you leave their files there, and only change the symbolic link.

Hope that helps.

[ Parent ]

libtool (4.00 / 1) (#69)
by fizbin on Mon Feb 26, 2001 at 10:15:44 AM EST

I know, it can be a bit daunting at first, but I would recommend downloading at least all of the documentation of libtool and figuring out what you would need to do to turn your piece of code into a libtool-ized shared library.

Along the way (In the libtool documentation), you'll get a decent introduction to how shared libraries work on several different Unix platforms, the perils of LD_LIBRARY_PATH, LD_RUN_PATH, et al. and there's even a good introduction to doing dynamic loading of shared libraries (what apache does with .so format modules, or what many pieces of software mean when they dynamically load "plug-ins"). You can get even more of a full-fledged introduction to the whole autoconf-automake-libtool set by reading the book available online at http://sources.redhat.com/autobook/autobook/autobook.html. (Or you could, I suppose, buy the actual paper-bound version, so long as you check out the errata)

Besides, if you're writing a library that anyone else will ever want to use, you'll eventually want libtool anyway, so you might as well learn now.

[ Parent ]
I recommend "Beginning Linux Programming" (4.00 / 2) (#60)
by kostya on Tue Feb 20, 2001 at 01:18:55 PM EST

You can buy it at fatbrain.com.

It is an incredible thorough book and takes you through all the basic topics. The examples are very good. Teaches you everything from Threads to Kernel Modules. Also a good bit of non-C stuff in there. I highly recommend it. I have yet to be disappointed: "Hmm, I wonder if it has something on X. Well, I'll be, there it is!"

Veritas otium parit. --Terence
Everything you ever wanted to do with C (4.50 / 4) (#63)
by BryanFeeney on Tue Feb 20, 2001 at 08:56:13 PM EST

Beginning Linux Programming by Wrox press (ISBN 1-861002-97-1) is an excellent book. It deals with
  • multi-threaded programs using forks, semaphores, and the pthreads library
  • GUI programming using Gtk+
  • Console programming using ncurses (for advanced console stuff like colours and moving text around)
  • Some advanced stuff on file i/o, e.g. using calls like open/write instead of fopen/fprintf for optimisations
  • Inter-process communication
  • Network programming using sockets
  • Database programming using the dbm library
  • CGI programming in C, which is not necessary the best application, but which gives a good grounding on string functions
  • and some misc stuff on shell programming, Perl, debugging tools, make, TCL, and an introduction to writing kernel modules (just in case you feel you need a real challenge!)
It's a pretty comprehensive book. The great thing is everything is nicely arranged, so you can pick and chose as you wish.
Bryan Feeney - http://www.bfeeney.uklinux.net/
"I still miss Windows, but my aiim is getting better."
GNU C++ for Linux (3.00 / 1) (#65)
by elvstone on Wed Feb 21, 2001 at 06:52:28 AM EST

I would recommend "GNU C++ for Linux" by Tom Swan. It is mainly about C++ but it also explains some C and it's a great introduction to Linux programming.

man oh man (none / 0) (#70)
by pjhunter on Mon Feb 26, 2001 at 06:17:06 PM EST

Nothing beats man pages when it comes to unix programming, and the key to unix programming is becoming intimate with /usr/lib and what lies within. However, the most important element of unix program is learning the propper development tools. GNU it. O'Reilly's GNU Make and GNU GDB are good books (although the man pages have all you really need.) Also gcc and ld are pretty important to get very familiar with (again nothing beats the man pages). Any of the dozens of books on the Standard C Library will be of a big help as a reference for the C runtime libs.

With regards to the nomenclature of C++, It was named with the idea of the ++ incremental operator in mind. For a brief time it was called C with Classes. C+ and ++C were also considered, but ultimately C++ pervailed. For another definition look at the appendix in Orwell's 1989.

Nearly but not quite (none / 0) (#71)
by pwhysall on Tue Feb 27, 2001 at 02:45:28 AM EST

Actually, the canonical reference documents for the GNU tools is not the man pages, but the info pages instead.
K5 Editors
I'm going to wager that the story keeps getting dumped because it is a steaming pile of badly formatted fool-meme.
[ Parent ]
If C == C then wouldn't C++ == C + 1? | 71 comments (65 topical, 6 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!