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

[Joshua Maurice]

#define synonym typedef

Again, as others have said in this thread, I can only hope that this
is only a joke. Using the preprocessor in this way is one of the most
offensive ways to obfuscate your code, rendering it unreadable and
unmaintainable by other people.

This is a gripe thread, so we're griping. However, "typedef" is what
the language standard says, so we all need to get used to it. "typdef"
is a misnomer, but it's a well defined misnomer which every competent
C programmer eventually comes to terms with, and treats it as second
nature. No longer is it the joining of two terms "type" "definition".
Instead it gains its own particular meaning divorced from its
constituent words.

One should not hide it with the preprocessor because that will only
cause /more/ confusion, which is exactly what we're trying to avoid,
aka what we're griping about.

 

[Jon]

I've been watching this discussion with some interest, because I would
have said that it "defines" a type. Sure, it just defines that type
to be identical to another type, but so what?

Note that declaring new types that are exactly integers but have
restricted conversion to or from integers is what most programmers
probably think "typedef" will do for them (think, enum). This is
compelling enough to pursue even though the concept has decidedly limited
usefulness (or uselessness) when applied to structs (and classes).
"defining a *new* type, incompatible with the original type except as
specified by the programmer" ("as specified" = via a cast, if you don't
use C++).

"typedef" as in "declare a new type in the likeness of the old type but
make no implicit conversions".

 

[Felix Palmen]

This is a gripe thread, so we're griping. However, "typedef" is what
the language standard says, so we all need to get used to it. "typdef"
is a misnomer,

How the *** do you people come to the conclusion that it wasn't given
its name quite intentionally? Someone made a mistake, huh?

Really, it is named after the task a programmer probably wants to
accomplish by using it. That's not that hard to understand and the name
just perfectly expresses the intention.

Sure you can complain that this doesn't exactly match C language
grammar. As someone in this thread pointed out (I forgot where exactly,
this thread just got huge), there are probably historical reasons for
that. But that really really doesn't make it a misnomer. It's just an
abstract concept (defining a custom type) accomplished by some other
technique in the layer below (= language "implementation").

Regards,
Felix

 

[Jon]

That depends on what you mean by "defines", and by "identical".
(Fortunately you avoided using the word "is", so we can avoid
the obvious jokes.)

I'm been assuming (well, stubbornly asserting) that to "define"
a type means to *create* a type. typedef doesn't do that.

And by the compound words derived from "type define", that is pedantic,
but, most cognitively convert that to "type declare" (typedec: declare a
new type "in the likeness" of the old type) in usage. Especially a new
programmer who is not quite as fastidious and has his mind on programming
at the higher level (that is, creating some piece of software).

"Aside": I think of "define" as the complement to "declare", not
"instancing of a type". Think "declare a function" vs. "define a
function" (knowing C++ clarifies this train of thinking: a class can be
declared in one place and defined in another and that has nothing to do
with "creation"/"instancing").

Right. Typedef creates a *name*, not a type.

But that is compiler-level knowledge (language/compiler implementation)
and not at the software programming (programmer) level. And does it
create a name at all internally or just bind to the other type (probably
up to the compiler developer and doesn't matter).

 

[Jon]

So here's the real point. A typedef does not create a type; it merely
creates a new name for an existing type.

But probably does not even do that but logically. Internally, it probably
(?) binds to the name of the old type.

The name "typedef" could
easily imply, at least to some people, that "typedef" does create a
new and distinct type,

Declare a new one, yes. Create a new one, no.

but it doesn't -- at least not on the C
language level.

At the *compiler* level, it may (?) just cause processing to occur that
effectively eliminates the programmer's "newly declared type".

On the other hand, typedef can be used to create a new "type" that's
*logically* distinct,

Which is in many cases *not* what is wanted. *If* the programmer just
wants to save typing function type syntax, fine (but then "alias" would
be better). If he really wants to declare a new type in the likeness of
the old type, then another construct is required.

 

[Joshua Maurice]

How the *** do you people come to the conclusion that it wasn't given
its name quite intentionally? Someone made a mistake, huh?

Really, it is named after the task a programmer probably wants to
accomplish by using it. That's not that hard to understand and the name
just perfectly expresses the intention.

Sure you can complain that this doesn't exactly match C language
grammar. As someone in this thread pointed out (I forgot where exactly,
this thread just got huge), there are probably historical reasons for
that. But that really really doesn't make it a misnomer. It's just an
abstract concept (defining a custom type) accomplished by some other
technique in the layer below (= language "implementation").

And so the argument continues in circles.

My claim is orthogonal to if it was purposeful or incidental by the
language writers. If incidental, then I claim that they made an
oversight. If purposeful, then I claim that they are wrong. I did not
go to the motivations of the writers or any possible mistakes on their
part, though perhaps you can draw that as an extension of my
argument.

My argument is simply that there are better possible choices of names
for "typedef" which are not as confusing if introduced from day 1.
Moreover, I claim that such a different name should have been used. I
am not trying to lay any blame.

Also, if a programmer uses typedef when he wants to define a new type,
then he's doing it wrong. He is not defining a new type. This is a
pedantic argument, but an important one. "Define a type" has a very
specific meaning w.r.t. typed programming languages. A type is defined
only when a new distinct type is introduced, and one can only talk
about distinct types w.r.t. a type checking system which distinguishes
between them, such as a compiler when doing function call argument
type checking. If a type name is introduced which is indistinguishable
from another type name w.r.t. the type checker, then no (new) type has
been defined. By that definition, "typedef" does not define types -
"typedef" does not "type-define" - "typedef" does not "typedef". Thus
it is a misnomer - the "simple meaning" taken from its constituent
words does not correctly describe the compound word.

"Sure you can complain that this doesn't exactly match C language
grammar."
Yes. That's exactly what we're doing. The C language standard is the
only relevant source of definitions in this debate. "typedef" is a
misnomer w.r.t. those definitions, so it is a misnomer.

 

[Jon]

I don't entirely agree. The word "int", consisting of the letters
'i', 'n', and 't', is not a type, it's a keyword.

It's a built-in type. The keyword is just the reserved name for the type.

It happens to
be the name of a type, but it is not itself a type.

What are types to the compiler if they are not names? A key (word) into a
symbol table. (IANACWY! (I am not a compiler developer yet!)). You are
not suggesting that as programmers, we should think of types as memory
locations or bits or registers...? For all practical purposes for the
programmer, the name of a type is the type. For the compiler developer,
it takes on a much more detailed meaning.

 

[Joshua Maurice]

Declare a new one, yes. Create a new one, no.

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

 

[Felix Palmen]

And so the argument continues in circles.

Indeed. I'm used to people with the ability to separate different levels
of abstraction (like, e.g. the modelling layers M0-M3 in UML).
Obviously, there are quite a few people without that ability.

What matters to the programmer does not at all need to exactly match
what matters to the compiler. When programming C, I like defining my
reference types (and also my enumeration types) using 'typedef' and I'm
doing nothing wrong at all.

 

[Seebs]

Also, if a programmer uses typedef when he wants to define a new type,
then he's doing it wrong. He is not defining a new type. This is a
pedantic argument, but an important one. "Define a type" has a very
specific meaning w.r.t. typed programming languages.

It has several very specific meanings.

A type is defined
only when a new distinct type is introduced, and one can only talk
about distinct types w.r.t. a type checking system which distinguishes
between them, such as a compiler when doing function call argument
type checking. If a type name is introduced which is indistinguishable
from another type name w.r.t. the type checker, then no (new) type has
been defined. By that definition, "typedef" does not define types -
"typedef" does not "type-define" - "typedef" does not "typedef". Thus
it is a misnomer - the "simple meaning" taken from its constituent
words does not correctly describe the compound word.

Except that both of those words have at LEAST two meanings which are
relevant. Even in the context of a typed programming language.

Yes. That's exactly what we're doing. The C language standard is the
only relevant source of definitions in this debate. "typedef" is a
misnomer w.r.t. those definitions, so it is a misnomer.

I don't think so. I think "definitions" is itself an example of a use
of the word "definition" which contradicts the sense of the C language.

We can't get away from the fact that we're using English to talk about C,
and English has multiple meanings for these words, and C programmers have
often used these words in multiple ways, relying on context to disambiguate.

-s

 

[Seebs]

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

Consider the declaration:
foo x;
In this declaration, "foo" is a type. Only it's not a type, because there
is no type "foo".

But wait!
typedef int x;
foo x;
Now, "foo" is a type. It has somehow come into being, as though it had
just been defined.

What "typedef" does is define things that you can use wherever you could
otherwise use a type.

-s

 

[Jon]

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

A macro is not "really" part of the language, but rather part of the
development environment. It is a mechanism with behavior that is
implemented by the preprocessor. PREprocessor. The #define just "defines"
the data to be used by the mechanism.
"This is the data to be used by the text replacement mechanism whenever
it is solicited with the given name". '#define' is pretty much just an
alias mechanism as is 'typedef'. It can then be argued, also, that there
is a better word than 'define' ('macro'!), since 'define' has well-known
semantic in programming languages. Yes, another bad (wrong?) choice for C
syntax.

#macro MY_TEXT "this is the text replacement mechanism data"

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


But in:
int x;
the word "int" is commonly referred to as a type. Perhaps it
shouldn't be, but it is. Similarly, in
struct foo x;
the phrase "struct foo" is a type.



Yeah, but same with the macro; the macro is really just a name for the
expansion of a hunk of code which was already typed somewhere.

We're creating a new mapping from a name to a thing, such that the
name can now be used in places where we use types. That is an awful
lot like creating a type.

We're also giving a definition of what a given thing is, and that
thing happens to denote a type.

A macro specifies the data to be used by the preprocessor mechanism. It
doesn't create any instances of the preprocessor text replacement
mechanism at each location where it is used. OTOH, one can instantiate a
C type, either directly or via an alias name.

 

[BartC]

It's a built-in type. The keyword is just the reserved name for the type.


What are types to the compiler if they are not names? A key (word) into a
symbol table. (IANACWY! (I am not a compiler developer yet!)).

ITYM IANACDY

 

[Jon]

<snip whole discussion of typedef>

For the love of all, let's take a step back and sort this out.

The term "define a type" has
a specific definition in C, this is a C question in a C forum, and so
that's the definition which matters.

"define a type": create an instance of type. "define a function": type
the function body. The C definition(s) of 'define' should probably be
deprecated.

The C compiler is a real computer program, so its memory is finite, so
it "understands" or "knows" only a finite number of types. The C
compiler has a built-in understanding of the built-in types, void,
char, short, int, long, float, double, and so on. It also has a built-
in understanding of other types, built recursively through the use of
production rules of a context free grammar. Pointers, signed,
unsigned, and so on. It does not list them all out because its memory
is finite, but the programmer does not "define", "declare", or
"introduce" these types - the user merely "references" / "uses" these
types.

That is not correct. The context of this thread is in the realm of
software development and not in the realm of language or compiler
development, the latter 2 of which are highly specialized subcategories
of SW dev requiring knowledge way beyond that of the programmer who
develops software outside of those 2 areas.

So, a programmer *does* declare and define types (and if you agree that
the C definition of "define a type" is obsolete, then add "create
instances of types" to the list).

The typedef keyword is not associated with "creating" / "defining" /
"introducing" / "declaring" types. It only "creates" / "defines" /
"declares" / "introduces" a name

Maybe it does, and maybe it doesn't, but that doesn't matter.

which is an alias for an "already
existing" / "already defined" / "already declared" / "already
introduced" type name.

I see no reason not to correctly distinguish declaration from defintion
from instantiation. They are well understood.

That is the primary important difference. "To define a type" is to
"create" / "define" / "declare" / "introduce" a new type and name

OK, quotation marks noted now, but I see no reason to do that when those
things are well understood and this group needs the vocabulary in an
on-going way. Declaration, definition, intantiation are (er, should be)
all distinct.

which is distinct from all other types and type names with regards to
the type checker. "typedef" does not do that. "typedef" "creates" /
"defines" / "declares" / "introduces" names which are not distinct
with regards to the type checker, and so by definition it does not
define new types. Thus typedef, from type-def, from type-definition,
is a misnomer. A much better name would be typealias.

Gee, thanks for taking the thread to "before square number one". :/

 

[Jon]

This, again, is from the C grammar or compiler view.

No, it's from the non-compiler-developer/non-language-implementer
perspective.

That's the wrong
way to think about it. The 'typedef' keyword is used by programmers to
define their types

No, it really is not because 'typedef' has not the capability to do that.
A "logical type" is an alias and not a "new type" and assumption that
'typedef' declares a new type is just plain wrong.

and a human being will most of the time define a
thing by giving it a name.

A boy name Sue. Do you *really* think that Sue's dad meant to *define*
the boy or just give him a name? (Bad analogy because dad did influence
(define?) Sue's behavior whereas 'typedef' does nothing of the sort... oh
well).

Although typedef is not the only way to do
this (struct and enum will also create a name in their special
namespaces),

Now they *do* declare and declare/define new types (the latter "in the
likeness of another type"), respectively.

it is ONE possible way and for many the preferred way.

Completely orthogonal to 'typedef'.

Compilers do not care about natural language semantics of a keyword,
programmers do; 'typealias' would be much less obvious.

Get it now/yet?

 

[Jon]

A typedef creates a new name for an existing type.

I don't think that is necessarily true at the compiler level, though. Did
you mean at the compiler level?

 

[Felix Palmen]

Get it now/yet?

YOU obviously don't. Nice going, dweeb...

 

[Joshua Maurice]

A macro specifies the data to be used by the preprocessor mechanism. It
doesn't create any instances of the preprocessor text replacement
mechanism at each location where it is used. OTOH, one can instantiate a
C type, either directly or via an alias name.

Again, in the C language:

Names are declared. Generally, to use a name, that name must be in
scope. (Excepting the evil known as K&R C.) To bring a name into
scope, you use a declaration.

Things have definitions. You can define a function, a type, a macro,
and so on. There is more to a function than its name; it has a body,
return type, parameter types, and so on. Most things have exactly one
definition (made more formal with C++'s One Definition Rule), but they
may have multiple declarations. Definitions tend to introduce a name
for the thing just defined, so most definitions tend to be
declarations.

As such, it is perfectly sensible and consistent to use "#define" to
define a macro. It is a definition; it tells the preprocessor
everything you possibly can about the macro, enough to "use" it in
every way. It's also a declaration; it associates a name with a
particular definition.

 

[Joshua Maurice]

It has several very specific meanings.


Except that both of those words have at LEAST two meanings which are
relevant.  Even in the context of a typed programming language.


I don't think so.  I think "definitions" is itself an example of a use
of the word "definition" which contradicts the sense of the C language.

What exactly are you trying to get at here? I'm not following at all.

We can't get away from the fact that we're using English to talk about C,
and English has multiple meanings for these words, and C programmers have
often used these words in multiple ways, relying on context to disambiguate.

Yes the English has several different meanings of "define". However,
in the context of C, and in the context of typed programming languages
at large, "define" as in "define a type" has only one definition.
There is no ambiguity. "To define a type" means to "create" or
"introduce" a new type to the compiler which is distinct from all
existing types w.r.t. the type checker. There is no other definition
of "define" in the phrase "define a type" in the context of
programming languages. Creating an alias for a type, aka defining /
declaring a new type name, is not defining a new type.

 

[Keith Thompson]

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. Or at least I'd like *some* term for a declaration
that actually creates something (like a function definition), as
opposed to just asserting that something exists (like a function
definition, or "extern int x;", or "struct foo;"). But there it is.

And it means that "struct foo { int i; };" isn't a definition, even
though it creates a type (and a name for that type). *sigh*

So a typedef declaration is a definition. What does it define?
I'd say it defines, not a type, but a new name for a type, but I'm
getting tired of arguing about that. }

But in:
int x;
the word "int" is commonly referred to as a type. Perhaps it shouldn't
be, but it is. Similarly, in
struct foo x;
the phrase "struct foo" is a type.

Hmm. I don't think of it that way. "int" and "struct foo" are
type names. When I say "int is a type", the word int refers to
the type, not to the name. (BTW, types are discussed in 6.2.5,
and type names in 6.7.6.)

So
int is a type
but
"int" is a type name.

[snip]

Did we ever figure out how many angels can dance on the head of
a pin?