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

[Keith Thompson]

Well, actually, as Keith pointed out, you "define" typedef names.  That's
the language the standard uses.

Could you quote please? Sadly, I do not have a C standard copy handy.
From what I can read from the C++03 standard, it never refers to
defining a name.

C++03, 7.1.3 The typedef specifier / 1

Declarations containing the decl-specifier typedef declare identifiers
that can be used later for naming fundamental (3.9.1) or compound
(3.9.2) types.

I would assume that C is the same in this regard. You declare names,
you define objects, functions, types, etc.

It's probably not a great idea to assume that C and C++ are consistent
in the finer points of terminology.

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.

An assumption that's been unstated so far in this thread is that
something is "defined" if and only if there's a "definition" for it.
I'm not entirely sure that's a safe assumption. It implies, for
example, that a struct type cannot be "defined", which is at least
odd.

BTW, if you want a copy of the C standard,
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>
is almost certainly good enough for your purposes.

 

[Felix Palmen]

I guess I wouldn't expect C to catch that kind of thing anyway. I don't
even expect C compilers to tell me when I mismatch genuinely different
types, many cases.

GCC does emit a warning in many cases. But I agree with you that the
issue that really matters here is understanding C's notion of
"compatible" types, a concept that is nowadays quite unique to C.

Regards,
Felix

 

[Seebs]

An assumption that's been unstated so far in this thread is that
something is "defined" if and only if there's a "definition" for it.
I'm not entirely sure that's a safe assumption. It implies, for
example, that a struct type cannot be "defined", which is at least
odd.

I'm not totally sure. The word "define" may not have picked up the
special magic associated with the word "definition". In which case,
the entire question of when something is "defined" is unrelated to
the question of where we have encountered its "definition". Eww!

I will say, noticing that the header for 6.7 (which explains
typedef) is "Type Definitions", I think we may be reaonably considered
stuck with the notion that, insofar as C distinguishes between
the categories, typedef does in fact introduce "type definitions".

-s

 

[Keith Thompson]

I see. Yeah, I think that's true, but I guess, it would never have
occurred to me to expect typedef to create a type which could be told
apart (except perhaps by an enthusiastic compiler) from a compatible
type, because that's not how I expect C to work. So that's a solution
to a problem I've not seen.

But it could have. "typedef" *could* have been defined to create
a new type that's distinct from the base type, just as char and
signed char are distinct types. And my concern (admittedly a minor
one that doesn't by itself justify a thread this long) is that
(I think) some programmers assume that typedef *is* defined that way.

 

[Seebs]

[Keith]
I certainly understand the idea of different levels of abstraction.
The point is, I can pay attention to more than one of them.
You seem to be insisting that the level at which typedef creates
a new logical type (a point which which I've agreed) is the only
one that matters, and that the fact that it doesn't create a new
type at the language level can be ignored.

It is the only level that matters for the naming of keywords. They
should be named after what is accomplished in the programmer's view.

Actually, I think that Keith's got a point here -- if you expected that
the compiler would detect passing a length where you expected a volume,
when both were typedefs of double, that would be a Bad Thing.

I still think typedef is a reasonable name, mind, but you do have to
be aware that it's a purely decorative distinction.

Consider, if you will, int32_t. It is very likely, on most systems that
have it, that it's actually the same type as either int or long. If you
think that the compiler will warn you when you mistakenly pass one of those
to a function taking int32_t, you are probably going to be disappointed.

Of course, this applies whether or not the "typedef" keyword is in use
at any point -- it's just a general quirk of C, that it is quite possible
that two logically distinct types (at the programmer level) will in
fact be the same type, and the compiler won't notice mismatches.

Leads to a question: Do any major compilers notice such mismatches as an
optional warning?

-s

 

[Felix Palmen]

Actually, that's a really interesting way of looking at it.

It's consistent in that definitions can occur only once. If typedef
would just /declare/ an alias, I could repeat it as often as I wanted
(which would be kind of handy for forward declarations of reference
types), but this is not the case.

Saying that it defines a type name is probably the best description for
typedef. But I'd still argue the distinction between type and type name
is irrelevant to the programmer most of the time -- and even if it
wasn't, the term 'typedef' would still match.

Regards,
Felix

 

[Keith Thompson]

GCC does emit a warning in many cases. But I agree with you that the
issue that really matters here is understanding C's notion of
"compatible" types, a concept that is nowadays quite unique to C.

I'm not aware of any cases where a gcc warning distinguishes between
a typedef name and the original type.

For example, on my system size_t is a typedef for unsigned int.
This line:
printf("sizeof(int) = %lu\n", sizeof(int));
produces this:
warning: format '%lu' expects type 'long unsigned int', but argument
2 has type 'unsigned int'
And if I change the "%lu" to "%u" there's no warning at all.

Apparently the portion of gcc that produces this particular warning
isn't even aware that sizeof yields size_t as opposed to unsigned
int.

Certainly compilers *can* use typedef information in warnings.
I wonder if any compilers other than gcc do so.

 

[Seebs]

But it could have. "typedef" *could* have been defined to create
a new type that's distinct from the base type, just as char and
signed char are distinct types.

I don't think it could have. Because, back when the type system was being
worked out, I don't think char was a distinct type from the signed/unsigned
variant it was the same as. Now, it could have been changed by C99, as
char sort of was, but I don't think people would have much wanted that.

The real problem is that there are some times when you clearly want that,
and other times when you clearly don't.

And my concern (admittedly a minor
one that doesn't by itself justify a thread this long) is that
(I think) some programmers assume that typedef *is* defined that way.

I have not yet seen any. I'd have been mildly surprised to encounter one,
although with the world as broad as it is, the chances are probably about
fifty-fifty that there's at least one profesionally-paid C programmer who
sincerely believes that typedef is a kind of a fish.

-s

 

[Joshua Maurice]

No.

I merely talk as though I don't think that distinction is, in fact,
crucial, or significant.  I don't think it actually changes anything
about how we program, or the meaning of any valid C program, or
anything else.


Nope.

First, let us look at the introduction of typedef, in section 6.7,
"Type Definitions".

        In a declaration whose storage-class specifier is typedef,
        each declarator defines an identifier to be a typedef name
        that denotes the type specified for the identifier in the
        way described in 6.7.5.

So, these are "Type Definitions" (that's the heading), and what they
do is *define* an identifier to be a typedef name.  More generally,
what is a "definition" in C?

6.7, Declarations, says:

        Semantics
        5 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.

So a typedef name does, in fact, have a "definition".  That definition
is described in detail under the heading "Type Definitions".

I think, given that the language standard refers to them as "type
definitions", it is not *entirely* beyond the bounds of reason for someone
to suggest that, in some way, they "define types".

Hmm. I am defeated on a minor point, apparently in C you can define
identifiers. Most unfortunate. However, it's still relatively clear
that typedef does not define types.

 

[Joshua Maurice]

It's probably not a great idea to assume that C and C++ are consistent
in the finer points of terminology.

Yes. Indeed. I was quite open that that's the best I had, and asked
for better. Apparently C++ decided to "clean" this up.

 

[Ian Collins]

But it could have. "typedef" *could* have been defined to create
a new type that's distinct from the base type, just as char and
signed char are distinct types.

Maybe that's the real reason why C++ was invented!

 

[Jon]

typedef can declare and/or define a new type name, but typedef does
not define new types.

I commented on what he said it implied to some people and corrected that
that was wrong: it implies to most people who misunderstand it that it
declares (not defines or creates) a new type. I don't think anyone would
ever assume definition or creation (which in C are of course the same
thing when talking about types). The only one who would assume that is
someone learning programming for the first time and does not understand
the difference between declaration and definition.

 

[Jon]

Yes, but there's one more step which I think you're taking implicitly,
so let me clear it up.

struct foo { int x; };
foo is a type name. The above line is a type definition and a type
declaration.

It's a type declaration. No storage reserved so it is *not* a definition
by the standard. That's the way I have understood "definition" as used in
C: as instantiation.

struct bar;
bar is a type name. The above line is a type declaration. It is not a
type definition.

It's not a definition. It's an *incomplete* type declaration.
('incomplete' modifies 'declaration').

typedef struct foo foo2;
foo2 is a type name. It refers to a type.

It's a typedef name. It refers to a typedef.

We normally say "foo" is a type, and we can also say that "foo2" is a
type. It's a certain loose use of the terms involved, but it's
generally accepted and generally is not error prone, ambiguous, or
confusing. Formally "foo" and "foo2" are not types but are type
names.

'foo' is a type name. 'foo2' is a typedef name.

"struct foo { int x; };" introduces a new type name. Formally it
declares a type name.

It declares a type with the identifier 'foo'.

"typedef struct foo foo2;" introduces a new type name.

No, it declares a typedef name 'foo2'.

Formally it
declares a type name.

It doesn't.

However, unlike "struct foo { int x; };" which defines a (new) type,

That just declares a type. It doesn't define one.

"typedef struct foo foo2;" does not define a type.
Correct.

Both declare type
names,
No.

but only one defines a type.

Neither define a type.

 

[Jon]

But one defines a type-name, and as you've noticed, it's not really
confusing to people to refer to a type-name as a type.

Best to start using "identifier" instead of "type name" probably from
here on forward.

 

[Jon]

Well, actually, as Keith pointed out, you "define" typedef names.

Actually, you "declare" them.

That's the language the standard uses.

No, it isn't. There are typedef "declarations", but not typedef
"definitions".

 

[Jon]

No.

I merely talk as though I don't think that distinction is, in fact,
crucial, or significant. I don't think it actually changes anything
about how we program, or the meaning of any valid C program, or
anything else.



Nope.

First, let us look at the introduction of typedef, in section 6.7,
"Type Definitions".

Section 6.7 Declarations
Section 6.7.2 Type Definitions

As 6.7.2 only discusses typdefs, the section name "Type Definitions"
obviously refers to the C typedef construct and not any more general
meaning.

In a declaration whose storage-class specifier is typedef,
each declarator defines an identifier to be a typedef name
that denotes the type specified for the identifier in the
way described in 6.7.5.

So, these are "Type Definitions" (that's the heading),

No. Look at the example. It specifically refers to them as declarations,
not definitions. Here are the examples:

typedef T type_ident;
type_ident D;

and what they
do is *define* an identifier to be a typedef name.

No, the first example *declares* a typdef name. type_ident is a typedef
name. D is an identifier.

More generally,
what is a "definition" in C?

6.7, Declarations, says:

Semantics
5 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;

Can't have a definition without storage reservation then so "typedef T
type_ident;" cannot be a definition.

- for a function, includes the function body
- for an enumeration constant or typedef name, is the (only)
declaration of the identifier.

So a typedef name does, in fact, have a "definition".
No.

That definition
is described in detail under the heading "Type Definitions".

No it isn't, see above.

I think, given that the language standard refers to them as "type
definitions",

It doesn't.

it is not *entirely* beyond the bounds of reason for
someone to suggest that, in some way, they "define types".

First premise is incorrect so your conclusion is also incorrect.

 

[Jon]

BTW, if you want a copy of the C standard,
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>
is almost certainly good enough for your purposes.

Newer (2 years):

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1425.pdf

 

[Jon]

I'm not totally sure. The word "define" may not have picked up the
special magic associated with the word "definition". In which case,
the entire question of when something is "defined" is unrelated to
the question of where we have encountered its "definition". Eww!

I will say, noticing that the header for 6.7 (which explains
typedef) is "Type Definitions", I think we may be reaonably considered
stuck with the notion that, insofar as C distinguishes between
the categories, typedef does in fact introduce "type definitions".

Reanalyze and see that "Type Definitions" (6.7.7) is a subsection under
"Declarations" (6.7) and the example and the text in that section
specifically show that a typedef *declaration* which introduces a typedef
name, not a type. Apparently, the heading of 6.7.7 came from recomposing
'typedef' into it's literary terms and is bound to be as confusing as
'typedef' iteself when taken literally. Example from section 6.7.7:

typedef int MILES;
MILES distance;

From the std: "The type of 'distance' is int...'. If a typedef
declaration introduced a type, then the type of 'distance' would have
been MILES. Hence, a typedef declaration introduces no type, only a
typedef name.

 

[Jon]

No. That is the definition of a type

Not according to the standard. And probably not how most use "definition"
in the C world.

- it tells the compiler its
members names, types, and layout. It's also a type declaration - it
associates a name with a type.


This is neither a type declaration nor type definition.

It's a "definition" if one wants to use the vocabulary of the standard. I
noted above that I don't like it, but that's how it is. It's another bad
C thing.

 

[Jon]

It is true because that's what the language standard says, so it's
true at the compiler level, source code level, and any other relevant
"level".

I was asking him whether he meant at the compiler level because it seems
that he has been talking about that. An implementer can do what he wants
behind the scenes as long as it meets the spec and the spec doesn't have
anything to say about the data structures of compilers.