N
Nick Keighley
Nick Keighleywrote:
I maintain that ex-ISO-Pascalers write better organized code.
of course.
of course.
C
CBFalconer
Ben said:
That's C code, not Pascal code. In proper Pascal you do some
things quite differently, to take proper advantage of look-ahead
through f^, etc.
N
Nick Keighley
he's trying to refute your statement that being an ex- (or maybe
current) ISO Pascal programmer led to you having a particular "good"
programming style. He did this by quoting some of your C code
which he presumably thought was not particularly Pascal like
(and presumably not particularly good).
--
Nick Keighley
Whereas Europeans generally pronounce my name the right way
('Ni-klows Wirt'), Americans invariably mangle it into 'Nick-les
Worth'. This is to say that Europeans call me by name, but
Americans call me by value.
A
Antoninus Twink
As usual, CBF doesn't take his own topicality medicine. "You'll get
better answers on comp.lang.pascal", as the refrain usually goes.
C
CBFalconer
Nick said:
Well, if he doesn't consider it good C code, that's his privilege.
I, of course, disagree.
D
David Thompson
This is conflating two things. C header (#include'd) files are just
text, the same as source files; by _convention_ (only) header files
contain only declarations (and some compiletime definitions) of things
'published' from one module for use by others.
You can write the same declaration of an external routine or object in
a header file and #include it, or directly in the source file(s) that
use it, and as far as the compiler is concerned it's the same. Using a
header file is (with rare exceptions) better practice; it allows you
to edit the declaration in only one place if it changes.
The declaration of an external (referenced) function, in either place,
doesn't need 'extern'; that of an object does.
Yes. Except that in C<99, with implicit int, 'auto x;' is a
syntactically valid decl but 'x;' isn't, and similarly 'extern foo();'
but not 'foo();' But for function defn, 'foo(parms)optpdecs{body}' and
'extern foo(parms)optpdecs{body}' are both valid.
Sort of. First, a declaration or definition with 'extern' doesn't
always declare external linkage! If the same object or function was
previously declared with 'static' = internal linkage, that 'wins'.
Second, you can write an extern object declaration in block scope,
although it's very rarely needed and IME is considered poor style.
It may be a philosophical question if this 'gives' static duration. It
certainly _refers_ to an object with static duration and (a name with)
external linkage, whereas without extern it would _define_ an auto
object with no linkage. But only the object itself really has
duration, not the declaration of it or reference to it, and the object
is defined in a declaration at file scope not block scope.
Man, those hysterical raisins are having fun.
- formerly david.thompson1 || achar(64) || worldnet.att.net
text, the same as source files; by _convention_ (only) header files
contain only declarations (and some compiletime definitions) of things
'published' from one module for use by others.
You can write the same declaration of an external routine or object in
a header file and #include it, or directly in the source file(s) that
use it, and as far as the compiler is concerned it's the same. Using a
header file is (with rare exceptions) better practice; it allows you
to edit the declaration in only one place if it changes.
The declaration of an external (referenced) function, in either place,
doesn't need 'extern'; that of an object does.
Yes. Except that in C<99, with implicit int, 'auto x;' is a
syntactically valid decl but 'x;' isn't, and similarly 'extern foo();'
but not 'foo();' But for function defn, 'foo(parms)optpdecs{body}' and
'extern foo(parms)optpdecs{body}' are both valid.
Sort of. First, a declaration or definition with 'extern' doesn't
always declare external linkage! If the same object or function was
previously declared with 'static' = internal linkage, that 'wins'.
Second, you can write an extern object declaration in block scope,
although it's very rarely needed and IME is considered poor style.
It may be a philosophical question if this 'gives' static duration. It
certainly _refers_ to an object with static duration and (a name with)
external linkage, whereas without extern it would _define_ an auto
object with no linkage. But only the object itself really has
duration, not the declaration of it or reference to it, and the object
is defined in a declaration at file scope not block scope.
Man, those hysterical raisins are having fun.
- formerly david.thompson1 || achar(64) || worldnet.att.net
K
Kenny McCormack
David Thompson said:
Oops, now you've done it. In the religion of CLC, you are not being
allowed to be saying that, any more than you are allowed to use the
S-word. There could exist a mythical machine where the header files are
not even files at all (Yes, really, mama. I read that right there on the
CLC!)
C
Chris Dollin
Kenny said:
RISC OS C is not mythical and has the standard headers embedded in the
compiler.
(It also has provision to get the headers from files, but it doesn't
/need/ to do that.)
J
James Kuyper
Chris said:
Also, David was talking about user-written C header files, not standard
headers. The standard headers don't need to be stored as source code
files, but user-written header files must be.
C
CBFalconer
Chris said:
McCormack is a troll. However, the system header files are not
required to be files, and are not permitted to be diddled by the
user. So, as usual, the troll is supplying mis-information. Note
that this means include files within the '<>' markers, not those
within the "" markers.
R
Richard
Yup. It's up there with Heathfield's proclamation that there is no such
thing as Global Variables in C.
R
Richard
Chris Dollin said:
There is no need in question. The point is that the file itself (if you
use it) is no different than .c. It can hold anything and frequently
does in badly administered code bases!