Comments requested: brief summary of C

[Dave Thompson]

``C treats all blanks space as equivalent, so line breaks
and indents are for readability only.''

So #define FOO 10
is the same as #defineFOO10 ?

Aside from the typo and the fact that the conventional term is white
space or whitespace, with no comparand (or whatever it's called) this
can only be read as meaning one whitespace is equivalent to another
whitespace, which is correct except for preprocessor and literals; it
is not reasonable to read it as saying whitespace is equivalent to an
empty string. So a better counterexample is
#define FOO 10
#define FOO
10
or "this is a string" "this\tis\na string"

(points I more-or-less agree with snipped)

``More generally, array[n] is equivalent to *(array + n) and in
fact is defined as such.''

No it isn't. It is equivalent to *((array) + (n))
The added parens are important. If your method
was actually used then the following would
fail:

a[i, j];

which is of course silly anyway, unless i actually (expands to
something that) has (relevant) side effects

Which would be equivalent to *(a + i, j)

Which would end up dereferencing the value of ``j''
as opposed to *((a) + (i, j))

No it wouldn't; given a is an array or pointer, a[i,j] is legal only
if j is an integer type, in which case *(a+i,j) is a constraint
violation. I don't see any case *of this particular transform* where
extra parens are needed, although it wouldn't hurt to use them to
emphasize/clarify the atomicity of the components.

``int array[20];
for (i = 0; i < 20; i++)
{ { code involving array; } }''


``i < sizeof array / sizeof array[0]''
is the more common convention

In this newsgroup it is, but IME not universally; a #define or
possibly enumerated value used in both places is also common, and
(sadly) so are magic numbers.

It is more automatically/robustly safe, especially when packaged in a
macro, and especially if you add one of the clever tricks to error out
on a pointer, and might better be promoted on those grounds.

But you may want to cast it to signed, or make i unsigned, for those
@#* compilers that warn noisily about comparing signed to unsigned.

- David.Thompson1 at worldnet.att.net

 

[Greg Barron]

Aside from the typo and the fact that the conventional term is white
space or whitespace, with no comparand (or whatever it's called) this
can only be read as meaning one whitespace is equivalent to another
whitespace, which is correct except for preprocessor and literals; it
is not reasonable to read it as saying whitespace is equivalent to an
empty string. So a better counterexample is
#define FOO 10
#define FOO
10

Where's your continuation? This won't work. You need:

#define FOO \
10

Cheers,

 

[Nils Petter Vaskinn]

On Mon, 01 Mar 2004 07:09:18 GMT, Dave Thompson


Where's your continuation? This won't work. You need:

I don't think it's intended to work. It's intended to prove that "all
whitespace isn't created equal" since in the example above a spece between
FOO and 10 isn't the same as a newline between FOO and 10