If you could change the C or C++ or Java syntax, what would you like different?

[BartC]

Again, typedef creates a new name for an existing type; it does not
create a new type (unless you mangle the meaning of "create", "new",
and/or "type").

If the existing type is specified with a simple name, then typedef creates
an alias, or synonym for that type.

If the 'existing' type is more elaborate than that, then you are
constructing a type spec, built using pointers, arrays, structs,
size/const/width/storage attributes, functions (with argument types and
return values), built-in types, and previous typedef names.

This type-spec may or may not have previously been constructed elsewhere in
the source (using another typedef, specified in full, or some combination);
but it doesn't matter, because semantically the underlying typespec (what
you get when flatten out any typedef names) is treated the same way by the
compiler.

The typedef is useful in source code, as a convenient way of re-using a
complex typespec in many places (where #defines won't work because of the
convoluted nature of C typespecs), for assembling complex typespecs in
stages, and for abstracting a particular typespec.

(I've some experience of compiling typedef-like statements in my own
language:

* My 'typedef' statement (which I just call 'type'), *does* create a
distinct type, which creates all sorts of problems, with type-matching,
overloading, inheritance, and all that sort of thing (most of which I just
ignore, and which C has done well to steer clear of...)

* Having a 'typedef' that *doesn't* create a distinct type, as in C, is
actually more difficult. (Macros will sort of do it, as my typespecs are
linear, but have the same sort of scope problems as C. Besides I think
macros are a naff way of doing many things..

* The case where a new type name is defined simply in terms of another (eg.
typedef A B, which seems simple enough, I found created a few special
problems of its own. I've already said above I think this is a different
kind of typedef from the rest.)

My wife chose to change her last name when we got married. This did
not create (or even "define") a new person, merely a new name for
an existing person. (If she's a new person, it's only figuratively.)

That's not a good analogy for the C type system; there can only be one
physical instance of your wife, whether as Mrs Thompson, some either name,
or anonymous. But the same complex type spec can appear in many different
places in source code, either whole or in pieces, and each whole or part can
be typedefed or not.

 

[BartC]

Again, typedef creates a new name for an existing type; it does not
create a new type (unless you mangle the meaning of "create", "new",
and/or "type").

If the existing type is specified with a simple name, then typedef creates
an alias, or synonym for that type.

If the 'existing' type is more elaborate than that, then you are
constructing a type spec, built using pointers, arrays, structs,
size/const/width/storage attributes, functions (with argument types and
return values), built-in types, and previous typedef names.

This type-spec may or may not have previously been constructed elsewhere in
the source (using another typedef, specified in full, or some combination);
but it doesn't matter, because semantically the underlying typespec (what
you get when flatten out any typedef names) is treated the same way by the
compiler.

The typedef is useful in source code, as a convenient way of re-using a
complex typespec in many places (where #defines won't work because of the
convoluted nature of C typespecs), for assembling complex typespecs in
stages, and for abstracting a particular typespec.

(I've some experience of compiling typedef-like statements in my own
language:

* My 'typedef' statement (which I just call 'type'), *does* create a
distinct type, which creates all sorts of problems, with type-matching,
overloading, inheritance, and all that sort of thing (most of which I just
ignore, and which C has done well to steer clear of...)

* Having a 'typedef' that *doesn't* create a distinct type, as in C, is
actually more difficult. (Macros will sort of do it, as my typespecs are
linear, but have the same sort of scope problems as C. Besides I think
macros are a naff way of doing many things..

* The case where a new type name is defined simply in terms of another (eg.
typedef A B, which seems simple enough, I found created a few special
problems of its own. I've already said above I think this is a different
kind of typedef from the rest.)

My wife chose to change her last name when we got married. This did
not create (or even "define") a new person, merely a new name for
an existing person. (If she's a new person, it's only figuratively.)

That's not a good analogy for the C type system; there can only be one
physical instance of your wife, whether as Mrs Thompson, some either name,
or anonymous. But the same complex type spec can appear in many different
places in source code, either whole or in pieces, and each whole or part can
be typedefed or not.

 

[Seebs]

So, the type isn't defined, but the content is. Under this definition
of terms, a typedef does not define types because nothing defines
types. Rather unsatisfying, but we can still claim that typedef is a
misnomer under these definitions of terms.

Perhaps, but a "typedef" is still under the heading 6.7, "Type Definitions".

I believe that the standard's intent is pretty clear. It's what Rui
Maciel has said in the above quote: a declaration gives a name to a
thing without necessarily fully specifying the implementation or
reserving storage, and a definition reserves storage if necessary and
fully specifies the implementation - it "creates" it.

Right. And a typedef fully specifies the implementation of the new type
name. Which makes it a "type definition", according to the standard's
labeling.

-s

 

[Joshua Maurice]

Perhaps, but a "typedef" is still under the heading 6.7, "Type Definitions".


Right.  And a typedef fully specifies the implementation of the new type
name.  Which makes it a "type definition", according to the standard's
labeling.

I think I am done with this thread, barring new arguments. Suffice to
say, I think you do not know what "type" means, and you invent meaning
to the term "define a type" aka "type definition" which few others
share.

 

[Seebs]

I think I am done with this thread, barring new arguments.
Okay.

Suffice to
say, I think you do not know what "type" means,

It is entirely possible. I would be a little surprised, given that I was
one of the people who worked on the language in question in the C standard,
but you never know, sometimes we miss stuff.

and you invent meaning
to the term "define a type" aka "type definition" which few others
share.

I am quoting the standard. The standard calls typedef statements
"Type Definitions". That's the heading. That's what they're listed as
in the table of contents.

We could argue that their choice of words is not ideal, but it strikes me
as absolutely unambiguous that the standard uses the term "type definition"
to refer to a typedef. Furthermore, the explanations given under the
standard's definition of the term "definition" show that a typedef is
clearly the definition of a "type name", which is a thing that can be, in
contexts where the "name" is implicit, referred to as a "type".

-s

 

[BartC]

Again, typedef creates a new name for an existing type; it does not
create a new type (unless you mangle the meaning of "create", "new",
and/or "type").

If the existing type is specified with a simple name, then typedef creates
an alias, or synonym for that type.

If the 'existing' type is more elaborate than that, then you are
constructing a type spec, built using pointers, arrays, structs,
size/const/width/storage attributes, functions (with argument types and
return values), built-in types, and previous typedef names.

This type-spec may or may not have previously been constructed elsewhere in
the source (using another typedef, specified in full, or some combination);
but it doesn't matter, because semantically the underlying typespec (what
you get when flatten out any typedef names) is treated the same way by the
compiler.

The typedef is useful in source code, as a convenient way of re-using a
complex typespec in many places (where #defines won't work because of the
convoluted nature of C typespecs), for assembling complex typespecs in
stages, and for abstracting a particular typespec.

(I've some experience of compiling typedef-like statements in my own
language:

* My 'typedef' statement (which I just call 'type'), *does* create a
distinct type, which creates all sorts of problems, with type-matching,
overloading, inheritance, and all that sort of thing (most of which I just
ignore, and which C has done well to steer clear of...)

* Having a 'typedef' that *doesn't* create a distinct type, as in C, is
actually more difficult. (Macros will sort of do it, as my typespecs are
linear, but have the same sort of scope problems as C. Besides I think
macros are a naff way of doing many things..

* The case where a new type name is defined simply in terms of another (eg.
typedef A B, which seems simple enough, I found created a few special
problems of its own. I've already said above I think this is a different
kind of typedef from the rest.)

My wife chose to change her last name when we got married. This did
not create (or even "define") a new person, merely a new name for
an existing person. (If she's a new person, it's only figuratively.)

That's not a good analogy for the C type system; there can only be one
physical instance of your wife, whether as Mrs Thompson, some either name,
or anonymous. But the same complex type spec can appear in many different
places in source code, either whole or in pieces, and each whole or part can
be typedefed or not.

 

[Jon]

The word "incomplete" has a specific meaning in C and you can't tell
without more context whether "struct bar" is or is not an incomplete
type.

You many have been using the word in some other way but (a) that's
going to be confusing since the word has a technical meaning related
to types and (b) the ordinary meaning on "incomplete" does not seem
to apply here either.

I'm sure you're probably right, but I did find the term for the
associated construct in the standard last night. If I run across it
again, I'll post where. (Note that I *don't* usually consult the standard
directly).

It declares a tag 'foo'. The tag is an identifier, but its rather
misleading to say that the type (which is "struct foo") has the
identifier 'foo'. It's different in C++, of course, where this really
does name the type 'foo'.

I'll *always* "trip up" on those subtleties in here because I don't
really use C but rather C++ but use a lot of simple C-like code unless
there is some compelling reason to bring in C++ constructs (and many
times I find that to be so). So "sowwwy" if it gets annoying, but I don't
plan on using straight C ever again (I haven't in over a decade). Anyway,
I *try* (and suceed) at forgetting C-isms that I will never use and have
no use for.

It's a declaration that defines a name (a typedef name).

Given that there is much confusion in regards to "declare/declaration"
vs. "define/definition", I find it very bad form to use one to describe
the other.

That the
way I say it based on the language used by the standard, but I am not
that bothered by the exact terminology. What is the difference that
you are trying to draw out here? What is it about "introduces a new
type name" that makes you answer with a "no"? It seems like a
perfectly reasonable way to express what it happening.

'typedef' != 'type'. (Which is *just* the basis of this whole
subthread!).

Yes, formally it is a declaration that defines a typedef name.

A typedef name is not a type name.

That is the correct use of the terms,

No it is not.

but what value is there in
making this distinction? What problems will thinking of this
declaration as "defining a type" lead to? The original argument
about typedef stemmed from the possibility of confusion.

And it is ironic that even the standards document writers are confused
about typedef as exhibited by the heading of secion 6.7.8 of draft n1425.

You
yourself said that some people might think (erroneously) that a
typedef makes a new type so it's important to know what it really
does (it introduces a synonym).

So, quite ironic then that the committee thinks it does (!).

But the struct declaration above
really does introduce a new type,

*declares* one. Please try not to drag 'introduce' into this discussion
and stick with 'declare' and 'define' (I am "assert" that only those 2
terms are necessary and desired and that the standard is not quite as
authoritative as some people think it is given the "loose" (or even
incorrect) use of important terminology).

so it seems to me quite harmless
(and also natural) to say that it defines a type.

I wouldn't apply for a job writing standards then if I was you. (No
offense).

 

[Jon]

There's also other kinds of definitions in C.

Function definitions don't reserve storage.
Macro definitions don't reserve storage either.

The term "external definitions"
only applies to definitions of objects and functions.

This subthread is about declaration and definition of *types*. Under the
microscope is 'typedef'. (!)

 

[Jon]

It's simple to explain what typedef does. I don't think anyone here
is actually confused about what it does. The argument has all been
about how appropriate words and phrases are when talking out what it
does.

Given the debate, I suggest the term be deprecated and replaced in the
standard. Someone, I don't remember who, suggested 'typealias'. Sounds
like a big win all around for so small a change. Existing code will not
be affected. Of course that would mean the committee and language
designers would have to "suck it up" a bit. (I get the impression that
the non-technical issues are bigger chasms to get across than the
technical ones).

 

[Ben Bacarisse]

Even in modern C, numeric types are implicitly converted. The fact that
int and long are incompatible shows up when you have pointers to them.
For example:

int *ip = NULL;
long *lp;
lp = ip; /* constraint violation */

But I suppose in K&R C, pointer types were implicitly converted as
freely as integer types.

Yes, very freely. I don't have a clear memory but using a simulator
I've been able to remind myself of what cc was like. The above code is
accepted silently.

Right, but the argument types weren't part of the function type, so
there was no requirement to diagnose the call as an error. Even in
modern C, non-prototype function declarations are still legal, and the
above code's behavior is undefined, but it could easily work as expected
(or blow up spectactularly).

The thing is I don't think that it's an error in K&R C. There was no
concept of "undefined" and in most cases people seemed to assume that,
provided they have the right picture of what the compiler is doing,
their code will work.

I suppose the type system in K&R C, or pre-K&R C, might not have been
defined rigorously enough for the idea of two types being distinct but
otherwise identical to make sense. (I'm thinking in particular of
pre-K&R C as it existed just before typedef was introduced.)

That's certainly true, but as far as I can tell it's also true of K&R C
after typedef came along. I can't think of any way to tell if two types
with the same representation are actually distinct in K&R C.

 

[Jon]

It's simple to explain what typedef does. I don't think anyone here
is actually confused about what it does. The argument has all been
about how appropriate words and phrases are when talking out what it
does.

Given the debate, I suggest the term be deprecated and replaced in the
standard. Someone, I don't remember who, suggested 'typealias'. Sounds
like a big win all around for so small a change. Existing code will not
be affected. Of course that would mean the committee and language
designers would have to "suck it up" a bit. (I get the impression that
the non-technical issues are bigger chasms to get across than the
technical ones).

 

[Jon]

There's also other kinds of definitions in C.

Function definitions don't reserve storage.
Macro definitions don't reserve storage either.

The term "external definitions"
only applies to definitions of objects and functions.

This subthread is about declaration and definition of *types*. Under the
microscope is 'typedef'. (!)

 

[Jon]

The word "incomplete" has a specific meaning in C and you can't tell
without more context whether "struct bar" is or is not an incomplete
type.

You many have been using the word in some other way but (a) that's
going to be confusing since the word has a technical meaning related
to types and (b) the ordinary meaning on "incomplete" does not seem
to apply here either.

I'm sure you're probably right, but I did find the term for the
associated construct in the standard last night. If I run across it
again, I'll post where. (Note that I *don't* usually consult the standard
directly).

***** News server down but found the above info now:

6.2.5 (2) "incomplete types (types that describe objects but lack
information needed to determine their sizes)"

6.2.4 (22) "A structure or union type of unknown content (as described in
6.7.2.3) is an incomplete
type. It is completed, for all declarations of that type, by declaring
the same structure or
union tag with its defining content later in the same scope."

It declares a tag 'foo'. The tag is an identifier, but its rather
misleading to say that the type (which is "struct foo") has the
identifier 'foo'. It's different in C++, of course, where this really
does name the type 'foo'.

I'll *always* "trip up" on those subtleties in here because I don't
really use C but rather C++ but use a lot of simple C-like code unless
there is some compelling reason to bring in C++ constructs (and many
times I find that to be so). So "sowwwy" if it gets annoying, but I don't
plan on using straight C ever again (I haven't in over a decade). Anyway,
I *try* (and suceed) at forgetting C-isms that I will never use and have
no use for.

It's a declaration that defines a name (a typedef name).

Given that there is much confusion in regards to "declare/declaration"
vs. "define/definition", I find it very bad form to use one to describe
the other.

That the
way I say it based on the language used by the standard, but I am not
that bothered by the exact terminology. What is the difference that
you are trying to draw out here? What is it about "introduces a new
type name" that makes you answer with a "no"? It seems like a
perfectly reasonable way to express what it happening.

'typedef' != 'type'. (Which is *just* the basis of this whole
subthread!).

Yes, formally it is a declaration that defines a typedef name.

A typedef name is not a type name.

That is the correct use of the terms,

No it is not.

but what value is there in
making this distinction? What problems will thinking of this
declaration as "defining a type" lead to? The original argument
about typedef stemmed from the possibility of confusion.

And it is ironic that even the standards document writers are confused
about typedef as exhibited by the heading of secion 6.7.8 of draft n1425.

You
yourself said that some people might think (erroneously) that a
typedef makes a new type so it's important to know what it really
does (it introduces a synonym).

So, quite ironic then that the committee thinks it does (!).

But the struct declaration above
really does introduce a new type,

*declares* one. Please try not to drag 'introduce' into this discussion
and stick with 'declare' and 'define' (I am "assert" that only those 2
terms are necessary and desired and that the standard is not quite as
authoritative as some people think it is given the "loose" (or even
incorrect) use of important terminology).

so it seems to me quite harmless
(and also natural) to say that it defines a type.

I wouldn't apply for a job writing standards then if I was you. (No
offense).

 

[Jon]

Not quite. As others have said before, the typedef construct does
not create a type. It is implemented "for syntactic convenience
only". Yet, the name does expresses the intention, but not the one
some people (the majority) expect it to have. The typedef construct
does not define a new type but it does specify a type definition to
be attributed to an identifier. To put it in other words, a typedef
construct sets the type definition of a certain identifier. This
makes all the sense in the world.

Sounds reasonable: "A typedef defines a type specification (aka,
"definition") but does not define a type". Or said tersely (and for
maximum confusion as C afficionados seem to like), "A typedef defines a
type but does not define a type". A new language is necessary just to get
the terminology under control! It looks like the mantra that goes "adding
keywords is evil" spills over into the documentation of the language
also! The wording of the standard needs an overhaul for sure. The (draft)
standard document(s) is(are) still contradictory in the relevant
sections.

I think I'll call my language "A Breath of Fresh Air".

 

[Ben Bacarisse]

I was going to reply in detail but then...

No it is not.

Here I am agreeing with you and you contradict me. I don't see any
point in a discussion of this sort.

<snip>

 

[Jon]

I was going to reply in detail but then...


Here I am agreeing with you and you contradict me. I don't see any
point in a discussion of this sort.

I thought you were saying that what you wrote was "the correct use of the
terms".

 

[Jon]

Also, whereas *I* try to keep the terms separate ("declare" and
"define"), the standard (I have been reading) says that definitions *are*
declarations. Of course, there are "defintions" and then there are
"definitions", which should not be confused with the literal meaning of
the term.

Section 3 of the standard, "Terms, definitions, and symbols", really
needs to be expanded to introduce the terminology used in the rest of the
document and to disambiguate also.

I hope this thread sends up a red flag to committee members and they act
on it (not that an incremental improvement in the spec would make C any
more viable though).

#define typealias typedef

=)

 

[Tim Rentsch]

But it doesn't create a new thing, it just creates a new spelling for an
existing block of code.


So that's a declaration, not a definition, even though it defines...
argh.

It turns out the standard does define the word "definition" (I should
have checked that earlier). C99 6.7p5:

A declaration specifies the interpretation and attributes of a set
of identifiers. A definition of an identifier is a declaration for
that identifier that:
-- for an object, causes storage to be reserved for that object;
-- for a function, includes the function body;
-- for an enumeration constant or typedef name, is the (only)
declaration of the identifier.

Which isn't quite as coherent as I'd like. I'd rather be able
to say that a definition is a declaration that creates the entity
it declares. [snip elaboration]

The word 'definition', as the Standard uses the term, assigns a
meaning to an identifier. It is the identifier that is being
defined; the "content" or "value" (ie, the /definiens/) given to
the identifier provides the "meaning" of the identifier. Notice
the phrasing in the passage quoted above: "A definition /of an
identifier/ ..." (emphasis added).

This usage is perfectly consistent with how 'definition' is used
in ordinary English. See for example any of the regular online
dictionaries, or this entry

http://en.wikipedia.org/wiki/Definition

on wikipedia.

 

[Tim Rentsch]

Except in this case where the distinction is crucial.

Also, C standard technically, you don't "define" names, you "declare"
names. You "define" objects, function, variables, types, and so on.

No, it's names (more precisely, identifiers) that are defined.
The supplied types, initial values, or function bodies, provide
the value, or meaning, of the identifiers being defined. A
definition is a mapping from a term (words, names, or identifiers)
to "meaning"; it is the word, or name, or identifier, that is
being defined. This statement holds in ordinary English, and
it is also consistent with where the Standard defines the term
'definition' in 6.7p5.

 

[Keith Thompson]

Before it happens, "foo x;" is not a valid declaration, because foo doesn't
denote a type. After it happens, "foo x;" is a valid declaration, because
foo denotes a type. There was no type denoted by "foo" previously.

But it's not a new type, and it wasn't created by the typedef.

An existing type changed from not being denoted by the name "foo" to
being denoted by the name "foo".

[...]

I'd say that they are two types, which happen to be the same. It's a new
thing, it just happens to be identical to an old thing. Here's the thing.

I'd say that you're mangling the meaning of the word "two".

A name is not the thing it refers to.

Once you've got all your headers included, then size_t is a type, and
unsigned int is a type, and they happen to be the same type.

"size_t" is a type name, and "unsigned int" is a type name. They are
two different names for the same type. There are not two types here,
just one.

But before that typedef was hit, size_t was not a type. The size_t type
has come into existence -- even though it's just a reference to another
type.

The distinction is in the name, because a type is not just a way of
representing data, but a mapping from a name to a representation of data.

I disagree. I don't think a type-name is part of the type; it's just a
name that refers to a type.

Okay, jump over to UNIX for a moment:
$ echo "foo" > a
$ ln a b

The "ln" command here has created a link, not a file, but it's definitely
created a thing, and the thing it created turns out to have the same exact
semantics as the thing created by the first command, which definitely
created a new file. (Assume there wasn't already a file named a or b.)

Yes, "ln" created a link (which refers to a file), just as "typedef"
creates a type name (which refers to a type).

Sure, it's actually creating a link, not a new file, but the effect is the
same as though it created a file -- you have a thing which is not distinct
in any way from a file, which is no less a file than the other thing, and
so on.

So after those two commands, do you have two files? I don't think so.
If you had two files, for example, you could append data to one without
affecting the other.