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

[Keith Thompson]

Oh and by the way .. even a standard can have some controversial points.

I wasn't aware that this one was controversial. You're the only
person I've ever seen who insists that typedef introduces a new
type after having had it explained.

If it was really a synonym, the following should be interpreted the
same:

char * a, b, c;

and

typedef char * string
string a, b, c;

That doesn't follow. typedef doesn't act on tokens, it acts on types.
It's a semantic construct, not a macro.

"typedef char *string;" creates a synonym for the type char*.
"string a, b, c;" creates three objects of type char*.

Given "typedef char *string;", do you argue that "char*" and "string"
are distinct types?

Or, to avoid irrelevant syntactic issues, consider this:

typedef char *string1;
typedef char *string2;

Do you argue that string1 and string2 are two distinct types?
If so, can you present a sample C program that demonstrates that
they're distinct, i.e., that the identifiers "string1" and "string2"
cannot be used entirely interchangeably? (Preprocessor stringizing
doesn't count.)

 

[Keith Thompson]

It's not a matter of applying or not applying "some human abstraction".
You and I are just apply *different* abstractions to the same construct.
And the one I'm using matches the one used by the C standard.

typedef does not define a type. It defines a name for a type.

What probably causes some confusion is that a typedef can be combined
with another declaration, so a single declaration (a) creates a
new type and (b) defines a synonym for that type. These are still
distinct actions. (a), which creates the type, is not a typedef;
(b) is a typedef, which does not create a type.

In fact the keyword "typedef" is syntactically treated as a storage
class specifier, which is certainly counterintuitive. It was done that
way because "typedef" was a relatively late addition to the language.
The syntax for declaring and defining array, struct, union, and pointer
type had already been established. When the need for type synonyms was
seen, the new feature had to be added without breaking existing
constructs.

If I were designing the C language from scratch today, I would
certainly do it differently.

 

[Felix Palmen]

That doesn't follow. typedef doesn't act on tokens, it acts on types.
It's a semantic construct, not a macro.

"typedef char *string;" creates a synonym for the type char*.
"string a, b, c;" creates three objects of type char*.

Given "typedef char *string;", do you argue that "char*" and "string"
are distinct types?

You didn't get the point. Not even close. Maybe you didn't want to.

 

[Felix Palmen]

What probably causes some confusion ...

Just try -- for a second -- to realize there is no confusion at all.
Then think about why people decided to give typedef its name. Probably
to confuse people, right?

 

[Keith Thompson]

You didn't get the point. Not even close. Maybe you didn't want to.

Then perhaps you could explain the point more clearly. It's quite
possible that I'm missing something you're trying to say.

1. "typedef" does not define a type.

2. By "define a type", I mean "create a new type".

3. "typedef" creates a synonym for an existing type. That existing type
may, in some cases, be created by the same declaration that includes the
typedef, but it's not created by the typedef itself.

4. Since "typedef" does not define a type, "typedef" was a poor name
choice.

Which, if any, of the above numbered statements do you disagree with,
and if so, why?

 

[Kenny McCormack]

typedef does not define a type. It defines a name for a type.

Amazing. Simply amazing.

Yet 99% of people will use it to "define a type".[/QUOTE]

The funny thing is that I am certain that at least 90% (probably 99%) of
working C programmers have had no contact with and no knowledge of the
sacred C standards documents. They just get their job done and go home
at 5 to their families.

And they define types using typedef, with nary a care.

 

[Kenny McCormack]

Then perhaps you could explain the point more clearly. It's quite
possible that I'm missing something you're trying to say.

1. "typedef" does not define a type.

2. By "define a type", I mean "create a new type".

Most people use the term "create a new type" to mean "create a new type".

By your logic, the dictionary does not define words. Which, I'm sure in
your twisted mind, it doesn't (as you - or one of your socks - will no
doubt explain that to me any minute now)...

--

No, I haven't, that's why I'm asking questions. If you won't help me,
why don't you just go find your lost manhood elsewhere.

CLC in a nutshell.

 

[Felix Palmen]

Then perhaps you could explain the point more clearly.

I did, more than enough. As long as you refuse to think about the
/meaning/ of a typedef (to the programmer, that is .. YES that's one
abstraction level ABOVE your standards), this discussion ist just
pointless.

 

[Keith Thompson]

I did, more than enough. As long as you refuse to think about the
/meaning/ of a typedef (to the programmer, that is .. YES that's one
abstraction level ABOVE your standards), this discussion ist just
pointless.

If you don't understand that typedef doesn't define a type, then you
don't understand typedef.

I agree, this is pointless (unless you're willing to explain just
what you're talking about).

 

[Felix Palmen]

If you don't understand that typedef doesn't define a type, then you
don't understand typedef.

I agree, this is pointless (unless you're willing to explain just
what you're talking about).

*plonk*

 

[Jon]

Eh? I know you didn't. You suggested a #define. I was commenting on
only on that and, in particular, the value you claimed it would have
for new programmers.

I know where you're coming from: "God created all things, therefore God
must exist", and "If all you have or know is C, then everything looks
like a thumb". "New programmer" does NOT mean "new *C* programmer". Why
perpetuate "crazy" constructs unnecessarily? Yes, 'alias' is better than
'typedef'.

 

[Keith Thompson]

*plonk*

Just out of curiosity, did anyone else understand the point he was
trying to make?

 

[Willem]

Keith Thompson wrote:
) Then perhaps you could explain the point more clearly. It's quite
) possible that I'm missing something you're trying to say.
)
) 1. "typedef" does not define a type.
)
) 2. By "define a type", I mean "create a new type".
)
) 3. "typedef" creates a synonym for an existing type. That existing type
) may, in some cases, be created by the same declaration that includes the
) typedef, but it's not created by the typedef itself.
)
) 4. Since "typedef" does not define a type, "typedef" was a poor name
) choice.
)
) Which, if any, of the above numbered statements do you disagree with,
) and if so, why?

None of the above. I am assuming that in number 2 above, you mean
something specific by "create a new type".
I'm assuming that your point is that a type cannot be a "new" type
when it is _technically_ a synonym of another type.

My argument is that, even though it may be a _technical_ synonym,
it need not be an _abstract_ synonym.

For example:
typedef int length;
typedef int volume;

It doesn't matter if the compiler warns you about mixing them or not.
Length and volume are obviously different types, when viewed as
abstractions. Which is what HLLs are for.

So, in closing, I disagree with what I assume is your definition for
"create a new type".


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[BartC]

Of course it does. It's why its called TYPE DEF == typedef ....

It can be a convenient way of thinking about it.

But KT is right, it doesn't buy you anything other than a much more
convenient syntax for specifying types.

 

[Keith Thompson]

Keith Thompson wrote:
) Then perhaps you could explain the point more clearly. It's quite
) possible that I'm missing something you're trying to say.
)
) 1. "typedef" does not define a type.
)
) 2. By "define a type", I mean "create a new type".
)
) 3. "typedef" creates a synonym for an existing type. That existing type
) may, in some cases, be created by the same declaration that includes the
) typedef, but it's not created by the typedef itself.
)
) 4. Since "typedef" does not define a type, "typedef" was a poor name
) choice.
)
) Which, if any, of the above numbered statements do you disagree with,
) and if so, why?

None of the above. I am assuming that in number 2 above, you mean
something specific by "create a new type".

Yes. The type doesn't exist before, or in the absence of, the
declaration. It does exist after, or in the presence of, the
declaration.

For example, if I write:
struct foo { int x; };
then the type "struct foo" exists. If I don't, it doesn't.
The declaration creates the type.

I'm assuming that your point is that a type cannot be a "new" type
when it is _technically_ a synonym of another type.

Yes, except that I fail to see what the word "technically" adds to it.

My argument is that, even though it may be a _technical_ synonym,
it need not be an _abstract_ synonym.

For example:
typedef int length;
typedef int volume;

It doesn't matter if the compiler warns you about mixing them or not.
Length and volume are obviously different types, when viewed as
abstractions. Which is what HLLs are for.

So, in closing, I disagree with what I assume is your definition for
"create a new type".

Ok, so the *intent* of a typedef is to create something that can be
treated as a distinct type, even if the compiler doesn't enforce the
distinction. And if, given the above declarations, I write:

length len = 10;
volume vol = 20;
int z = len + vol;

then my program is logically incorrect, even though there is no error
that a compiler is going to complain about.

If that was Felix Palmen's point, then I agree (and it would have
been nice if he'd simply said so, or at least answered my direct
questions, rather than plonking me.)

My point is simply that that's not what "typedef" really means *in the
language*. And if you want to create a new type and have the compiler
enforce it for you, typedef won't do the job (but a struct will).

(Incidentally, I see that Kenny McCormack and Richard nolastname
have posted in this thread. If I don't respond to what they say,
it's because I haven't read it.)

 

[BartC]

I don't understand what you mean by "real world". In case you mean
"outside of programming" (i.e. mathematics) you are right.

I meant outside of programming, even outside of mathematics.

If you mean
"languages other than C" you are entirely wrong, though. As I'm
writing this, I'm thinking that out of all the languages I know,
Erlang is probably the only one where '=' does not explicitly stand
for "assignment".

There are plenty using ":=" (and various other forms) for assignment, such
as all the Algol-based ones for a start.

But yes, the C-style seems to be winning out. And designers exposed to these
languages will likely use "=" in new ones too.

It's a bit like the VHS vs. Betamax war; the better format lost (although
personally I preferred V2000 as superior to both...)

But that is besides the point. My point is that I think as humans we
have the capability to differentiate between symbols and their
meanings based on context.

You don't want to rely on context too much, otherwise you can end up with
code like this (from a real language):

if then then then=else; else else=then

But given this code snippet from an unknown language:

print a=b

what is your guess as to what it does? What about this:

print a:=b

?

 

[Ben Bacarisse]

Just out of curiosity, did anyone else understand the point he was
trying to make?

Well I didn't. The passing shot (quoted above) suggests that he was
making a point, disconnected from the C language, about how one should
think about a typedef'd type. However, I don't think that was the point
he was making earlier in the thread.

 

[Nick]

Just out of curiosity, did anyone else understand the point he was
trying to make?

I think so, and I tried to explain it, but you didn't understand me
either! It was to do - or at least, mine was - with the difference
between the current formal meaning of the word type and the sort of
informal meaning (more a "first-class type") that I suspect was floating
around when typedef came up - and the one that meant that typedef made
perfect sense to me and has never confused me since I encountered it.

It's that typedef creates a thing of the same status in C as an int or a
char. These can easily be thought of as "types" in a say a string of
words and brackets - with the identifier name in the middle - isn't
likely to be.

 

[Ben Bacarisse]

I know where you're coming from: "God created all things, therefore God
must exist", and "If all you have or know is C, then everything looks
like a thumb". "New programmer" does NOT mean "new *C* programmer". Why
perpetuate "crazy" constructs unnecessarily? Yes, 'alias' is better than
'typedef'.

I have no idea what this means, but I am not sure how much that matters.
I've expressed my view a clearly as I can and I don't think you've
misunderstood it, so there's little point in my saying more. I may be
incapable of understanding your point of view so we might as well just
leave it that we disagree about something.

 

[Keith Thompson]

I think so, and I tried to explain it, but you didn't understand me
either! It was to do - or at least, mine was - with the difference
between the current formal meaning of the word type and the sort of
informal meaning (more a "first-class type") that I suspect was floating
around when typedef came up - and the one that meant that typedef made
perfect sense to me and has never confused me since I encountered it.

It's that typedef creates a thing of the same status in C as an int or a
char. These can easily be thought of as "types" in a say a string of
words and brackets - with the identifier name in the middle - isn't
likely to be.

I'm not sure I understand you -- and if I do, I disagree.

I think that using the phrase "first-class type" is not helpful. That
phrase has an established (though vague) meaning that's not particularly
similar to what you're talking about.

Maybe there's a confusion between a name and the thing the name refers
to? For example, we can say that "int" is a type (referring to the
language-level abstract concept of an integer type with a certain
representation, operations, and so forth), or we can say that "int" is a
C keyword that *refers to* a type (unless it's preceded by "long" or
"unsigned"). "int" is the name of a type; "int" is a type. Those are
two very different things, but we call them both "int" in informal
discussion.

My point, again, is that "typedef" doesn't create a type. It creates a
name for a type.

Consider the following C code fragment:

typedef int word;
char *cp = 0;
int *ip = 0;
word *wp = 0;

cp = ip; /* constraint violation, LHS and RHS
have incompatible types */
cp = wp; /* constraint violation, LHS and RHS
have incompatible types */
ip = wp; /* valid, LHS and RHS have the same type */

How does this fit in with your idea that typedef "creates a thing
of the same status in C as an int or a char"?