jkl@csli.Stanford.EDU (John Kallen) (05/27/89)
In article <10213@claris.com> kevin@claris.com (Kevin Watts) writes: >I've never liked the typedef nonsense. C++'s approach is, IMHO, the way >C should have behaved from the beginning. Since I've never yet had to >convert any C code to C++, I've had no problems with compatability. Does anybody know the reason why structs are defined as they are in C? I.e. why do I have to say "struct foo" instead of just the tag "foo"? John. _______________________________________________________________________________ | | | | |\ | | /|\ | John Kallen | |\ \|/ \| * |/ | |/| | | PoBox 11215 "Life. Don't talk to me | |\ /|\ |\ * |\ | | | | Stanford CA 94309 about life." _|_|___|___|____|_\|___|__|__|_jkl@csli.stanford.edu___________________________
pcg@aber-cs.UUCP (Piercarlo Grandi) (05/28/89)
In article <9137@csli.Stanford.EDU> jkl@csli.stanford.edu (John Kallen) writes:
Does anybody know the reason why structs are defined as they are in C?
I.e. why do I have to say "struct foo" instead of just the tag "foo"?
There are others I can think of, but most importantly is to make the grammar
more palatable to a recursive descent parser. In this way, by looking at the
first token in a "statement" you know whether it is a declaration (begins
with a a storage class, "struct", a fundamental type name, ... all of which
are reserved keywords).
Typedef'ed names require
In C++ it is difficult (without infinite lookahead, i.e. context sensitive
parsing, just like Algol68) to distinguish declarations from imperative
statements, especially as they now may appear at any point in a block,
and especially as the '=' in an initializer can now be omitted again (even
if in a different way from early C, but with much the same ambiguities).
In certain contexts, some compilers require you to insert a storage class
specifier to help making the context less ambiguous. Indeed, I am now of the
opinion that it may help even the human reader to start any and every
declaration in C++ with the storage class, even if it is redundant (like
auto for locals and extern for globals).
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
karzes@mfci.UUCP (Tom Karzes) (05/29/89)
In article <9137@csli.Stanford.EDU> jkl@csli.stanford.edu (John Kallen) writes: > >Does anybody know the reason why structs are defined as they are in C? >I.e. why do I have to say "struct foo" instead of just the tag "foo"? I think one reason is that it allows pointers to foo before foo itself is actually defined. For example: struct foo { struct bar *pb; }; struct bar { struct foo *pf; }; If you tried to say "bar *pb;" before bar was defined, you'd get an error. (Note that although C is willing to assume the same machine representation for all structure pointers, this is not true for arbitrary types (e.g., char *, int *, etc.)
ark@alice.UUCP (Andrew Koenig) (05/29/89)
In article <878@m3.mfci.UUCP>, karzes@mfci.UUCP (Tom Karzes) writes: > In article <9137@csli.Stanford.EDU> jkl@csli.stanford.edu (John Kallen) writes: > > > >Does anybody know the reason why structs are defined as they are in C? > >I.e. why do I have to say "struct foo" instead of just the tag "foo"? > I think one reason is that it allows pointers to foo before foo itself is > actually defined. For example: > struct foo { > struct bar *pb; > }; > struct bar { > struct foo *pf; > }; You can say `foo' instead of `struct foo' in C++. It handles the forward reference problem in one of two ways. One is to allow `struct foo' as a type name even if `foo' has not yet been defined. That makes the example above legal. The other way is to allow the existence of a type name to be established before the definition in some circumstances: struct bar; struct foo { bar *pb; }; struct bar { foo *pf; }; -- --Andrew Koenig ark@europa.att.com