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

[Keith Thompson]

Two replies. First is a new one. Second is a rehash.

So, the C standard clearly states that certain headers define the type
size_t. However, size_t is not a type. It is a type name. Why do you
choose the interpretation "the header defines the type which is named
size_t"?

Because 7.17p1 says "The following types and macros are defined ...".
If you want to argue that that's wrong and/or inconsistent, fine, but
that's what it says.

[...]

Do you really think
that the C standard intends the reading which would have us conclude
that
typedef MILES int;
is a type definition for the type which is named int, and
typedef METERS int;
is also a type definition for the type which is named int?

I really think that the C standard intentionally says that a typedef is
a "type definition", and that it "defines a type". I dislike its choice
of wording, I don't entirely understand it, and I'm not going to defend
it. But it's right there in black and white.

 

[Keith Thompson]

No, because when you use typedef you are attributing a type
definition to a new identifier, which will then serve the role as a
type specifier.

[...]

It's amazing that after ALL my posts in this thread, there are STILL
people who think my statement that "typedef" is indeed a good name had
something to do with it's language standard definition.

Not even understanding my point makes it quite pointless do discuss it.

Maybe I'll try a last time in this thread (Because, after posting it so
often, I think I learned to express it more comprehensibly):

There's a need for defining a type when working with typed languages. So
there is a conceptual function "define type". C /supports/ this
conceptual function by several language constructs, where typedef is one
of them and the only one able to name your type in the global name
space. It happens to support the conceptual function of defining your
type by just setting an alias to an existing named or anonymous type,
but that's most of the time completely irrelevant to the programmer.
Therefore, the name "typedef" is fine, it's what you want to do
conceptually by using it.

So you think it's "fine" for the language to use a term that make
sense only on a layer of abstraction higher than the language itself,
making it difficult to discuss the concept on the language level,
and leading to the confusion that you deny even exists.

I don't.

I understand your point, at least the point that you're making now.
I don't agree with it.

 

[Seebs]

But it's correct to claim that it's *either* int or long.

Yes. But if all we know is that there's *some* such setup, and it's
possible that the type used is an extended type which is not otherwise
exposed to us...

And in some sense, such uses of #if mean that you have two different
programs, one where word is the same type as int and one where
word is the same type as long. (That's not a very strong argument;
as far as the standard is concerned, preprocessing directives are
as much a part of the language as anything else.)

Hmm. Yeah; I tend to see it as being a single program with slightly
undetermined characteristics. Since it's easy to write code which
doesn't depend on those characteristics, I tend to ignore them.

Sure, if that's the only model you use.

I work effectively with size_t, for example, by thinking of it as a
distinct thing; I called it an "stype" in another post. But I still
keep in mind that it's really an alias for something else.

I see. I tend to have only one model at a time, but switch between
them.

Maybe (though "type1", "type2", and "type3" are perhaps not the best
choice for keeping the concepts straight).

The question is, what does "type" mean? Since the term is used, IMHO,
reasonably consistently by the standard, using the word "type" to refer
to some other concept, however useful that concept might be, is unwise.

I am pretty sure that it is actually used for all three of those senses
in at least one case in C99. When we are told that typedef does not

There are reasons to want to know something other than making direct use
of them. Knowledge is itself A Good Thing.

Hmm. I suppose there is that.

And, as I've said before, knowing what typedefs do and don't actually do
can be helpful in understanding error messages, or their absence. One
example: if you pass a pointer of the wrong type to time(), the error
message might refer to type long rather than type time_t.

Hmm. You have a point:

t.c:6: warning: format '%d' expects type 'int', but argument 2 has type 'long
unsigned int'

That's for sizeof(foo).

Your model of C *programming* is consistent. Your model of the C
*language*, I suggest, is not. Using a higher level of abstraction
is good, but so is being aware of what it's based on.

I'm pretty sure my model of the language is also consistent, I just don't
usually invoke all of it. I tend to ignore parts of it except when I'm
doing something specific to them.

But you understand where the "circumstance or necessity" comes
from, right? That's all I'm saying, that a good C programmer should
understand (and not deny the existence of) the underlying language
rules on which all our wonderful abstractions are based.

I see. Okay, yeah, I'd buy that.

I think, jumping back about for conversations, Felix's argument isn't that
you can't usefully be aware of these things, but that the name "typedef"
works perfectly well for the thing you're probably going to want to think
about when programming.

And there's some special rule about structs, isn't there? (Too lazy to
look it up right now.)

That's where the "compatible types" magic comes in, two structure types
can be "compatible" if they have the same types of things, with the same
names, in the same order, and so on.

-s

 

[Seebs]

I really think that the C standard intentionally says that a typedef is
a "type definition", and that it "defines a type". I dislike its choice
of wording, I don't entirely understand it, and I'm not going to defend
it. But it's right there in black and white.

I would say that it defines the types MILES and METERS, both to be the
type int. It's basically like a glossary saying:
MILES: see /int/.

That's providing a definition of MILES. It's not providing a "new
definition", though!

Actually, I have a better way of talking about this in terms of "definitions".

Consider a glossary entry:

<term>: <definition>

Now, the thing after the colon is the "definition of <term>". But wait! The
whole *entry* is also the "definition of <term>". We use the word definition
both to refer to the thing as a whole, which tells us what <term> is, and
to the thing on the right side, which is the thing we are told is the meaning
of <term>.

That term overloading comes with us when we go to discuss "type definitions".
There are two things at issue; one is the mapping from a term to a definition,
and one is the definition. But the mapping from a term to a definition is
itself a "definition" in another sense.

Similarly, one thing is the mapping from a type-name to a "type", and the
other is the "type". But we sometimes refer to the mapping from a type-name
to a type as a "type". Which is, oddly, something that I've never once seen
confuse anyone in the previous twenty years, but as soon as we look at it
closely, we see multiple experienced C programmers having trouble articulating
it.

-s

 

[Rui Maciel]

There's a need for defining a type when working with typed languages. So
there is a conceptual function "define type". C /supports/ this
conceptual function by several language constructs, where typedef is one
of them

That isn't true. C's typedef construct does not define a type. All a typedef does is declare an
identifier which can be used as a type specifier and attributes to it a specific type. It only does
that due to it's purpose, which is syntatic convenience. That's why the following code works:

<code>

struct foo { //..something};
typedef struct foo bar;

void tester(struct foo param)
{
// do stuff
}


int main(void)
{
struct foo A;
bar B;

tester(A); // it works
tester(B); // it also works. It wouldn't work if bar was a new type

return 0;
}
</code>

In this example, declaring bar B is exactly the same as struct foo B. That's what a typedef does.
It's convenient but it doesn't do anything beyond this.

<snip/>


Rui Maciel

 

[Joshua Maurice]

I would say that it defines the types MILES and METERS, both to be the
type int.  It's basically like a glossary saying:
        MILES:  see /int/.

That's providing a definition of MILES.  It's not providing a "new
definition", though!

Give me a moment to ponder the rest of it, but could you answer this
one thing to guide my future discussion points?

Initially, you were of the opinion that MILES, METERS, and int were
all distinct types, (for whatever appropriate definition of
"distinct"). I again hope we're talking at a strictly formal language
level. In that context, MILES, METERS, and int are not distinct types.
They are the same type. The size of set of types in this discussion is
1.

I again bring up 6.7.7 Type definitions / 4
typedef int MILES, KLICKSP();
[...]
The type of distance is int, [...]

So, do you agree? Or do you want to use language which says that there
are 3 distinct types, MILES, METERS, and int?

 

[Joshua Maurice]

I would say that it defines the types MILES and METERS, both to be the
type int.  It's basically like a glossary saying:
        MILES:  see /int/.

That's providing a definition of MILES.  It's not providing a "new
definition", though!

Give me a moment to ponder the rest of it, but could you answer this
one thing to guide my future discussion points?

Initially, you were of the opinion that MILES, METERS, and int were
all distinct types, (for whatever appropriate definition of
"distinct"). I again hope we're talking at a strictly formal language
level. In that context, MILES, METERS, and int are not distinct types.
They are the same type. The size of set of types in this discussion is
1.

I again bring up 6.7.7 Type definitions / 4
  typedef int MILES, KLICKSP();
  [...]
  The type of distance is int, [...]

So, do you agree? Or do you want to use language which says that there
are 3 distinct types, MILES, METERS, and int?

Err, that snipped quote should read:

I again bring up 6.7.7 Type definitions / 4
typedef int MILES, KLICKSP();
[...]
MILES distance;
[...]
The type of distance is int, [...]

 

[Felix Palmen]

That isn't true. C's typedef construct does not define a type.

[...]

FAIL

 

[Rui Maciel]

Working with you must be a bundle of laughs. Every word questioned and
mulled over. Are you really so totally unable to adapt meanings to
common sense and context?

A key skill that is fundamental to the ability to understand a programming language and therefore
write decent software is to know and understand what specific language constructs do in a precise
manner. If you fail to do that then you are unable to fully understand what you are doing with the
code you hack away, let alone the code written by your coworkers.

This skill is even more important in discussions where the topic is exactly that: the precise way a
language construct works. If you wish to discuss how programming languages work then you discuss
exactly that: the precise way things works.

Considering this, if your best effort to discuss this sort of stuff demands that others "adapt
meanings" then it shows that you don't have a good grasp of the subject nor you do a good job
discussing this sort of stuff to begin with.

This whole thread is a lesson on how to identify people you would never
let near a development team.

If you believe it is a good idea to assemble a team of developers who shy away and have a hard time
understanding and discussing the precise way their tools of the trade work then I hope you enjoy
wasting your time hunting for bugs and fixing gotchas caused by nothing more than a poor
understanding of how your adopted programming language works.


Rui Maciel

 

[Ian Collins]

Working with you must be a bundle of laughs. Every word questioned and
mulled over. Are you really so totally unable to adapt meanings to
common sense and context?

This whole thread is a lesson on how to identify people you would never
let near a development team.

Every team needs a pedant (no offence to Keith!).

What would be a disaster is a team of pedants. Imagine the meetings!

 

[BartC]

Tim Rentsch wrote:

Yeah well why don't you take your fucking C and shove it up your ass.

LOL

(Also consider this is the first time I've ever used 'LOL' in 15 years of
internet...)

 

[BartC]

But now that you mention it, it would be great if the C programming
language offered a way to
declare a new type specifier which would be interpreted by the compiler as
a new, distinct type. By
doing that it would simplify the creation of new types (i.e., sidestep the
need to wrap stuff in
structs) and it would help programmers, particularly those developing
libraries, write cleaner,
safer code.

This would be opening a can of worms (with inheritance and all that crap).

Consider:

typedef int newint;

Can you pass a newint to a function that takes an int? (Apparently not,
according to your other post).

Can you do newint+newint? If not, then this will make life difficult. If
yes, then it means sometimes newint is treated as int, and sometimes it
isn't.

What about newint+int?

What type is the literal 1234?

Can one do newint=int without a cast?

And so on...

 

[Keith Thompson]

I work effectively with size_t, for example, by thinking of it as a
distinct thing; I called it an "stype" in another post. But I still
keep in mind that it's really an alias for something else.

[...]

Correction: I called it an "ltype", for "logical type" (with the
disclaimer that the term does not imply that an "ltype" is a kind of
type).

(I considered calling it an "stype", for "Seebs type", but thought
better of it.)

 

[Keith Thompson]

Okay, let's try an experiment.

Let us label terms:

type1: The underlying logical mapping of storage space to interpretation,
plus any magic flags that allow you to distinguish, e.g., between char and
signed/unsigned char, things like that.

That's a type.

type2: The mapping from a name to a type1.

I can't think of a simpler name for that than "the mapping from a name
to a type" (I dropped the '1' deliberately). I suppose you could call
it a "typedef", the abstract concept that a type definition creates, but
I'm not sure that's useful. (There's probably a node in the compiler's
symbol table that represents it.)

type3: The name that is mapped to a type1 by a type2.

Syntactically, that's a type-name. More specifically, the identifier
defined by a typedef is a "typedef name" (6.7.7p3), which is one
of several kinds of "type-name" (6.7.6).

With these, we can now say:

* typedef defines type3s, and creates type2s.

typedef defines typedef names, and creates mappings from typedef
names to types.

* typedef does not create a type1.

typedef does not create a type.

* typedef does not define a type1.

typedef does not define a type. (Oh? The standard seems to say
that it does; IMHO that's the result of sloppy wording.)

* "size_t" is a type3.

"size_t" is a typedef name.

* <stddef.h> defines a type2 named "size_t".

<stddef.h> defines "size_t" to be a typedef name (which is a
type-name); it creates a mapping from that name to some unsigned
integer type.

[...]

 

[Keith Thompson]

This would be opening a can of worms (with inheritance and all that crap).

Inheritance? We're talking about C, remember.

If I were proposing this, I wouldn't change the general behavior of
numeric types (or at least that would be a separate proposal).

Somebody suggested a new keyword "newtype" that acts like typedef except
that the new type is actually distinct. Consider:

Consider:

typedef int newint;

newtype int newint; /* changing the existing semantics of typedef is not
a reasonable option */

Suppose int and long happen to be the same size. Then int, long,
and newint are all distinct signed integer types with the same
representation.

Can you pass a newint to a function that takes an int? (Apparently not,
according to your other post).

Yes, just as you can pass a long to such a function.

Can you do newint+newint? If not, then this will make life difficult. If
yes, then it means sometimes newint is treated as int, and sometimes it
isn't.

Yes (otherwise there's not much point).

What about newint+int?

Yes, as for any "+" operation the operands are converted to a common
type.

What type is the literal 1234?

int, just as it's always been.

Can one do newint=int without a cast?

Yes, just as you can do long=int.

And so on...

For numeric types, "newtype" can't create a new type with arbitrary
characteristics; it can only create a new type with the same
characteristics as some existing type. The "usual arithmetic
conversions" would have to be expanded slightly, so that a numeric
type created by "newtype" is implicitly converted to the predefined
type it's based on.

Given C's prolific implicit conversions between numeric types,
using "newtype" to create a new *numeric* type wouldn't be all
that much more useful than a typedef; it would matter mainly
for pointer-to-newtype types. (For example, you'd be guaranteed
that passing an int* to time() would be a constraint violation;
currently it's either a constraint violation or perfectly legal,
depending on the implementation.)

<OT>
Ada has predefined integer types similar to C's, but they're
distinct types, and there are no implicit conversions between
them; furthermore, the user can create new integer types.
It means you need a lot more explicit conversions than in C.
(Literals are of an anonymous "universal integer" type, which can be
implicitly converted.) Personally, I don't think that's a bad thing.
Most expressions probably shouldn't mix numeric values of different
types anyway; if you're doing that, it may be a sign that you should
have declared your objects more consistently.
</OT>

But I wouldn't suggest changing C in this way; it would break too
much existing code (and too many C programmers' minds).

 

[Robert A Duff]

From: "BartC" <[email protected]>
Subject: Re: If you could change the C or C++ or Java syntax, what would you like different?
Newsgroups: comp.lang.c
Date: Sun, 24 Oct 2010 23:33:14 +0100
Organization: A noiseless patient Spider



This would be opening a can of worms (with inheritance and all that crap).

Well, other languages have worked this all out, without too much "can of
worms". For example, in Ada, one can say:

type T is new Integer;

to declare a new type, or:

subtype S is Integer;

to declare a new name for an old type (like typedef in C).

The idea is that T is a new type, with all the capabilities of Integer,
but you can't mix them. You can't assign a T to an Integer, you can't
pass a T to an Integer parameter, etc.

Well, except you CAN do those things, with an explicit type conversion.

The subtype "S" above, on the other hand, is pretty much like a typedef
in C.

And anything you can do with Integer, you can do with T (literals,
add them, etc.)

Consider:

typedef int newint;

Can you pass a newint to a function that takes an int? (Apparently not,
according to your other post).

If it's a new type (which is not the case for typedef in C), then,
no, you cannot.

Can you do newint+newint?

Yes. (Assuming you mean objects of that type.)

...If not, then this will make life difficult.
Indeed!

...If
yes, then it means sometimes newint is treated as int, and sometimes it
isn't.

No, not really. It means newint and int are isomporphic, but
can't be mixed without explicit conversions.

What about newint+int?
No.

What type is the literal 1234?

That's the most interesting question. The answer is: whatever the context
requires. This is of course foreign to C, where 1234 is of course an
'int'. In "X := 1234;" (or C syntax "x = 1234;"), the type of 1234 is
that of X.

Can one do newint=int without a cast?
No.

And so on...

Not sure what "so on" you have in mind, but the key point is that
if the programmer can define/declare an arbitrary number of integer
types, then "1234" should have its type determined from context.

- Bob

 

[Seebs]

So you think it's "fine" for the language to use a term that make
sense only on a layer of abstraction higher than the language itself,
making it difficult to discuss the concept on the language level,
and leading to the confusion that you deny even exists.

I think that's a little strong.

If you include the library as part of the language, the notion of
typedef as "defining types" clearly makes sense at that level.

-s

 

[Seebs]

That isn't true. C's typedef construct does not define a type.

According to the language standard, it does. It does not *create*
a type, but it definitely *defines* one.

-s

 

[Keith Thompson]

Hello Bob, welcome to the *other* language whose name is a hexadecimal
palindrome!

Well, other languages have worked this all out, without too much "can of
worms". For example, in Ada, one can say:

type T is new Integer;

to declare a new type, or:

subtype S is Integer;

to declare a new name for an old type (like typedef in C).

The idea is that T is a new type, with all the capabilities of Integer,
but you can't mix them. You can't assign a T to an Integer, you can't
pass a T to an Integer parameter, etc.

Well, except you CAN do those things, with an explicit type conversion.

I'm afraid that kind of thing would be difficult to add to C.

C allows any numeric type to be converted implicitly to any other
numeric types. For example, int and long are distinct types (which
may or may not have the same representation) but given:
int i;
long l;
you can write "l = i", "i = l", "i + l", "i * l", and so forth.
The language defines what conversions are done at run time.

[...]

I suppose you could define a new *kind* of integer types (and
floating-point, and complex, and maybe imaginary) that are *not*
implicitly convertible to and from other numeric types. But I don't
think it would go over very well.

 

[Seebs]

Every team needs a pedant (no offence to Keith!).

He's an excellent pedant.

What would be a disaster is a team of pedants. Imagine the meetings!

What meetings? If everyone were just careful about words in the
first place, we wouldn't need special arranged events to get
synchronized.

(The degree to which this is a joke is left as an exercise for
the reader.)

-s