C isn't for timid souls !

[Ian Malone]

"char" should only really be used for strings and for arrays of "bytes"
[yeah I know the idea char == byte is taboo but go look at network
code...] for protocols.

I don't know what you mean. The idea that char == byte is part of the
definition of "byte" in the C standard.

Possibly the char == octet taboo?

 

[gw7rib]

Here's some advice about how to programme in C:
(From
http://www.uni-muenster.de/ZIV/Mitarbeiter/EberhardSturm/PL1andC.html/)


Or perhaps timidness is not the problem.

Well, I'm going to stick my neck out and say that this list looks quite
a good idea, at least in parts.

The context seems to be that someone who doesn't know much C (and who
isn't intending learning much more) has to, or wants to, write a C
program for some reason. It would seem prudent to assume that the
program might be maintained by either the same programmer or someone
else who knows little C.

While experienced programmers find lines such as:

while ((c = fgetc(file)) != EOF)

a neat way of doing things (it's from Andrew Poelstra's post) it does
look confusing and in my view might be best avoided for a beginner or
inexperienced maintainer.

Now this makes perfect sense. How many times have people posted
perfectly plausible code to clc, saying "why doesn't this work?", and
the answer has been a lack of sequence points. It's possibly the most
frequently asked question here, despite it being in the FAQ.

And what leaps to mind first when you hear the question "Will this
macro work properly?"?

You don't need to use ++ or -- - and if you don't know exactly what
you're doing they are best avoided.

Another popular snag is finding that floating point numbers don't have
exactly the values you were expecting - often revealing itself when a
comparision unexpectedly returns false. You need to be aware of such
things.

The other items on the list also refer to things that could either
cause your program not to work properly, or to make it difficult to
read and understand. So in the context of advice to occasional C
programmers, it seem to all make sense.

Just my tuppenceworth...
Paul.

 

[Ian Malone]

The context seems to be that someone who doesn't know much C (and who
isn't intending learning much more) has to, or wants to, write a C
program for some reason. It would seem prudent to assume that the
program might be maintained by either the same programmer or someone
else who knows little C.


While experienced programmers find lines such as:

while ((c = fgetc(file)) != EOF)

a neat way of doing things (it's from Andrew Poelstra's post) it does
look confusing and in my view might be best avoided for a beginner or
inexperienced maintainer.

TBH this has one more, more serious, problem for someone unfamiliar
with the language, that c should be of type int.

Now this makes perfect sense. How many times have people posted
perfectly plausible code to clc, saying "why doesn't this work?", and
the answer has been a lack of sequence points. It's possibly the most
frequently asked question here, despite it being in the FAQ.

Well, I think the most idiomatic use of these things is the
for(ii=0; ii<SOME_NUMBER; ii++) { } and friends. The people
who ask the question here seem to have an obsession with the
bizarre rather than simply trying to get by in the language.
Your conclusion:

> if you don't know exactly what you're doing they are best avoided.

is sound.

Another popular snag is finding that floating point numbers don't have
exactly the values you were expecting - often revealing itself when a
comparision unexpectedly returns false. You need to be aware of such
things.

This isn't a C issue though, and there's no simple rule you can
apply to deal with it.
* Do expect rules of mathematics! (but with finite precision, integer
maths, type promotion and C operator precedence)

 

[Thad Smith]

In general though, if you need an integer type "int" is better to use.
For most platforms it is the "most efficient" size to deal with. So
something like

char x;
for (x = 0; x < 10; x++) { printf("Hello world\n"); }

Is probably not a good use for a char type.

For 8 bit processors, unsigned char gives much more efficient operation
when only 8 bits are needed. With C99 you can specify (u)int_fast8_t
for the fastest type for your platform, but, with the near exception of
gcc for the Atmel AVRs, C99 compilers don't exist for these processors.

 

[Richard Bos]

Here's some advice about how to programme in C: (From
http://www.uni-muenster.de/ZIV/Mitarbeiter/EberhardSturm/PL1andC.html/)


Or perhaps timidness is not the problem.

Well, no. If using PL/I makes you use that many exclamation marks, I'm
glad I use a sane language instead.

Richard