conventional core of C

[Tom St Denis]

I don't see it that way. I think it's a "bootstrap" problem. There's a
mutual recursion problem with computer languages. In order to
understand X you need to understand A and B. And to undertsand A you
need X and Y. And so on. Chapter 1 gives you a quick overview of the
language which enables you to bootstrap the rest. I remember being
very impressed with K&R partly because of this.

What I meant was that it quickly throws a lot of different material at
you [seemingly out of order] so as to [as you put it] bootstrap the
process. You aren't really meant to walk away from chapter one with a
deep understanding of the keywords it shows you just enough so that
you can read simple C programs and build up from there.

Nowadays little things like the K&R style args or "main()" are bad
form, so a lot of the verbatim examples in the book are out of date.
It's still better than reading [say] the ISO C spec for learning C
though

Tom

 

[Bill Cunningham]

strlen() doesn't add a \0 at the end of a string. So can you write
strlen()?

I'll give it a try. I might have to read some more.

Bill

 

[BGB / cr88192]

But what about struct? It's mentioned in the last chapters and I don't
know how one would just with the "C language" to right their own struct.

<--
If struct is excluded from the "conventional core" I've obviously
misunderstood the term.

(structs were added late to C, originally each member was in global
namespace, so you couldn't have two structs pointi{int x, int y} and
pointf{float x; float y;}, or the x and y would collide.
-->

this reminds me of a vaguely C-like DSL I used, which had an object system
which also exhibited a similar property:
really, there was only a single object type, with a single in-memory size
and layout, and all of the various types of objects all shared this common
layout.

although, I suspect probably in early C, the structs were overlapping, say:
struct foo_s { int xi, yi; };
struct bar_s { float xf, yf; };

xi and xf would have the same offset (and possibly yi and yf depending on
the field sized).
in this DSL, however, they would be given different offsets so as to not
collide WRT memory.

it was up to the developer to remember which fields were valid in which
objects.


this language was short lived, with later versions of the product instead
using C (first native, then in a bytecoded VM, where the bytecode was
typically JIT'ed on startup), and later creating another OO DSL (of vague
similarity to Java or C#...).