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

[Seebs]

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

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?

After "typedef char *str", the word "str" has become a type -- I can
consistently use it as though it were a type. I can use it to declare
variables, I can use it as the return type or in the prototype of a
function, and so on. I can pass it to sizeof. In short, it acts just
like a type. It has behavior equivalent to the behavior of, e.g.,
"float".

I think the key argument really does come down to the difference between:

char *s, t;
and
str s, t;

"str" is not just a thing which is substituted out for "char *" -- it's not
a macro. It's a single identifier which now denotes one of the derived types.

I guess, the reason I tend to think of it as "defining" a type is that
the resulting type name behaves more like one of the built-in types than
it does like spelling out the derivationof a derived type. Consider:

typedef int (*foo)(int);

Now, after I've done this:
int (*bar)(int);
foo bar;

Note that in one of these, the name of the thing declared is buried inside
the declaration, while in the other, it's just an identifier following a
type name. That feels a little like a definition.

.... Of course, now that I mention "definitions" and "macros", I suppose
there's a definite clash here with the semantics of #define.

-s

 

[Seebs]

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"?

This is an interesting counterpoint. However, it is certainly not
unheard of in C for multiple spellings of the same type to exist:

int *ip = 0;
signed int *sp = 0;
ip = sp;

But "signed int" and "int" both have the trait that, put at the
beginning of a comma-separated list of identifiers, they declare
a large number of things all of which have the same type. "char *"
does not have that trait, making it less like a primary type
and more like a derived type.

Typedef can turn a derived type into something that smells like
a primary type.

-s

 

[Ian Collins]

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?

I guess then you have to consider whether given

typedef struct { int n; } X;

either

typedef struct { int n; } Y;

or

typedef X Y;

defines Y to be identical to X.

 

[Keith Thompson]

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?

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.

Is that inconsistent with your understanding of what "define" means?

As for "identical", well, there's identical, and there's identical.
For example, as you know, two of char, signed char, and unsigned char
have identical characteristics, but they're three distinct types.

After "typedef char *str", the word "str" has become a type -- I can
consistently use it as though it were a type. I can use it to declare
variables, I can use it as the return type or in the prototype of a
function, and so on. I can pass it to sizeof. In short, it acts just
like a type. It has behavior equivalent to the behavior of, e.g.,
"float".

I think the key argument really does come down to the difference between:

char *s, t;
and
str s, t;

"str" is not just a thing which is substituted out for "char *" -- it's not
a macro. It's a single identifier which now denotes one of the derived types.

But that's just syntax. It has little to do with the underlying
concept, beyond being what's used to express it.

char *s, t;

is the syntax that expresses the concept "s is of type pointer-to-char,
t is of type char". For purposes of this discussion, I'd say there's
no relevant difference between "char *s, t;" and "char *s; char t;".

I guess, the reason I tend to think of it as "defining" a type is that
the resulting type name behaves more like one of the built-in types than
it does like spelling out the derivationof a derived type. Consider:

typedef int (*foo)(int);

Now, after I've done this:
int (*bar)(int);
foo bar;

Note that in one of these, the name of the thing declared is buried inside
the declaration, while in the other, it's just an identifier following a
type name. That feels a little like a definition.

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

Consider this. If typedef defines a type, then how do you describe
the distinction between this:

struct foo { int x; };
struct bar { int x; };

and this:

struct foo { int x; };
typedef struct foo bar;

? I'd say that "struct bar { int x; };" defines a type (a struct type)
and a name for that type ("struct bar"), whereas "typedef struct foo
bar;" only defines a name ("foo") for an existing type (the one defined
on the previous line).

 

[Seebs]

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

Is that inconsistent with your understanding of what "define" means?

Yes.

Here's the thing. Let's say I tell you what I think a word means; I am
*defining* that word. But I'm not *creating* a word -- I'm just telling you
what the word is. (Self-referentially, the word in question would likely be
"define".)

I think... Hmm. Here's the thing. In C, when referring to functions
or variables, it's pretty clear that a declaration tells you that something
exists, and a definition creates it. But in other contexts, a definition
just tells you what something is. I think you're probably applying the
C variables-and-functions sense of "define" here, while I'm just using the
general English sense of "define".

But that's just syntax. It has little to do with the underlying
concept, beyond being what's used to express it.

Perhaps, but it creates a difference in how the language behaves; I
can declare multiple items as pointers, with only one thing on the
line which logically implies pointerness.

is the syntax that expresses the concept "s is of type pointer-to-char,
t is of type char". For purposes of this discussion, I'd say there's
no relevant difference between "char *s, t;" and "char *s; char t;".

I think there's something about "char *s, t" that takes some thinking
about. In that, "char" is the type, and "*s" and "t" are the things
declared -- the * is not part of the type used for the whole set of
declarations, it's part of an individual declaration.

Ugh. My brain's fuzzy. What I'm trying to get at is, the thing at the
left side of a declaration of multiple variables is the base type of the
whole set, but then individual variables can be derived in various ways
(pointers, arrays, etc.). Without a typedef, there's nothing you can
put at the left side of a declaration of two objects which makes both of
them pointers. You can only declare objects of base types, not derived
types. After a typedef, somehow the thing you've typedefed starts
acting more like a base type.

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

Oh, certainly.

But I don't think of "defining" as "creating". Dictionaries don't create
words, they describe them.

? I'd say that "struct bar { int x; };" defines a type (a struct type)
and a name for that type ("struct bar"), whereas "typedef struct foo
bar;" only defines a name ("foo") for an existing type (the one defined
on the previous line).

Sure. But that name is now a "type" for purposes of the language, so
what it did was define a type, but not create a type. We're running into
the clash between plain-English "define" and variables-and-functions "define".

.... And come to think of it, in the struct case, it's used that way, where
"define" creates the type, and "declare" just tells you that it's there.

I think the thing is, I don't extend that usage beyond the specific
cases where the standard formalizes that distinction, so I fall back on the
plain English sense where "define" is used in the sense of "what dictionaries
do to words".

-s

 

[Joshua Maurice]

<snip whole discussion of typedef>

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

First, I would have you all read:
http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.8
It does not matter if you have a PHD in math, religion, philosophy, or
general computer science. I don't care if the weight of all of the
dictionaries of the world are against me. 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.

However, in order to be readable and to clear up any
misunderstandings, I'll try to avoid controversial terms where ever
possible.

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.

Then there are aggregate types, those with the struct keyword. When
you write
struct foo { int x; };
this tells the C compiler about a type. "It introduces a type" / "It
defines a type" / "It declares a type". The C compiler will internally
make a note. That note will contain (at least) 2 things:
The name of the type, ex: "struct foo"
The names, types, and layout of its members: ex: "{ int x; }"

When you write
typedef struct foo bar;
this tells the C compiler about a new type alias. "It does not
introduce a type" / "it does not define a type" / "it does not declare
a type". The C compiler will not internally make a note like above.
Instead, it will make a much smaller note which contains (at least) 2
things:
The name of the new alias, ex: "bar"
The name of the referred-to type, ex: "struct foo"

Note that
typedef struct foo { int x; } bar;
is /exactly/ equivalent to, and defined by the C standard as:
struct foo { int x; };
typedef struct foo bar;

The typedef keyword is not associated with "creating" / "defining" /
"introducing" / "declaring" types. It only "creates" / "defines" /
"declares" / "introduces" a name which is an alias for an "already
existing" / "already defined" / "already declared" / "already
introduced" type name. This alias is for most purposes entirely
equivalent to the aliased type name.

Finally, consider
typedef char* baz;
char* a, b;
baz c, d;
Yes "b and "d" do have different types, but that's simply a fluke of
the declaration syntax of C. "a", "c", and "d" still have the same
type. You can pass any of those three to the following function:
void f(char* );
or
void g(baz );
or
typedef char* xxx;
void h(xxx );
That is the primary important difference. "To define a type" is to
"create" / "define" / "declare" / "introduce" a new type and name
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.

 

[Joshua Maurice]

<snip whole discussion of typedef>

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

First, I would have you all read:
 http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.8
It does not matter if you have a PHD in math, religion, philosophy, or
general computer science. I don't care if the weight of all of the
dictionaries of the world are against me. 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.

Err, actually
http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.11
is what I intended, though you may need to read more to get an idea of
its context.

My mistake.

 

[Robert Redelmeier]

Please share your oppinion on anything you do not like in
the C or C++ or Java syntax (they're quite similar).

I'm shocked no-one has complained about the excessive requirement
for semicolons. \n should imply end-of-statement unless escaped (\?)

Another pet peeve is no simple way to read or print largish
arrays in a single [slow] printf() call. Something like
FORTRAN's implied DO loops.

-- Robert

 

[ClassCastException]

On Mon, 18 Oct 2010 08:46:46 +0100, Tom Anderson wrote:

[massive snip]

Believe me, I've seen worse. And savvy users may not like programs trying
to keep their own documents but that doesn't stop the programs themselves
from trying. These days iTunes is easily the worst commonly-encountered
offender but it's far from the only one.

Recently a friend asked me to help him get his iPhone contacts synching
with his Outlook contacts. Boy was it a pain.

First, there are several places where Windows wants to keep contacts.
Address Book comes with Windows and is one place (and the default iTunes
synch target on Windows); Outlook has its own. Address Book keeps it all
in a single .wab file in C:\Documents and Settings\$USERNAME\Application
Data\Microsoft\Address Book\ (how's that long and deeply nested path grab
you?!) and easily exports to .wab and CSV. iTunes doesn't even let you
*see* the contacts, just synch them(!); the phone does let you see and
edit contacts on the device. Where iTunes and Outlook keep their own
copies I still have no idea. None of them is in My Documents or any of
its subdirectories, though.

The first thing I did was ascertain that iTunes was synching the phone
contacts with Address Book instead of Outlook. I backed up the Address
Book .wab and told it to synch with Outlook instead -- and the Outlook
contacts list, which was missing a bunch of information (basically only
having the names and phone numbers and nothing else), clobbered the
phone's instead of vice versa. Good thing I backed everything up, huh? So
I told it to synch with Address Book again and it clobbered Address Book.
Argh. Restored Address Book's contacts from the backup.

I spent quite a while trying to use the Address Book contacts directly to
replace Outlook's. Address Book speaks wab. Outlook does not. Address
Book exports to CSV, but only the stripped-down data Outlook already had
-- probably how the Outlook contacts got set in the first place, Outlook
was installed and it sucked the Address Book contacts out via CSV during
setup.

Which made me suspect that Outlook was not treating the imported contacts
as last modified whenever they'd been last modified in Address Book but
as last modified when Outlook was installed. So they were viewed as the
newest version by iTunes's synch.

Damn.

Long story short, I manually edited every contact in Address Book -- most
of the entries had not had the Gender field set and had an obvious
correct choice for it -- then backed it up again and resynched it with
the iPhone. This restored the iPhone's contacts. Then I synched the phone
with Outlook, and that filled in all the missing data in the Outlook
contacts. Then I left the iTunes on his machine set to synch with Outlook
rather than Address Book.

Problem solved, I think, but it took about two whole hours. If I could
have simply gotten at an outlook.wab in some Outlook subdirectory of My
Documents (or even Application Data) and a phone.wab in some visible,
browseable file directory in the iPhone by browsing the iPhone as a mass
storage device via USB, it would have taken two whole minutes, most of
that watching a file copy dialog reporting its progress.

So what problems have we got here?

1. Everything likes to guard its contacts. Address Book at least leaves
them where a tech-savvy user that has some passing familiarity with
Windows can easily find them. iTunes and Outlook hide them better.
2. Devices that don't provide direct filesystem access via external tools
suck.
3. Corollary of both 1 and 2: Apple sucks.
4. Applications that have the same sort of data not being able to share
that data sucks; in particular, Address Book and Outlook only sharing
a limited pidgin vocabulary in common.
5. Corollary of 1 and 4: Microsoft also sucks.

We have had standard vcard and address book formats for years. There
really was no excuse for this.

I trust the lesson on the evils of applications trying to corral their
created documents has now been taught sufficiently.

I would agree that we need better management of that. For me, it's not
too bad - Firefox and Chrome save things to ~/Downloads, rtorrent saves
to wherever i tell it to, i don't use a tool for my phone or camera
(they're mass storage devices - why on earth would i?), and i don't have
any other downloaders. Well, unless you count sftp, ftp, and so on, but
those put things where you tell them.

There's part of it right there. Most of those have different defaults,
pretty much all of them do at least let you change the target directory,
and in practice you end up having to type ~/downloads (or whatever) into
every damn thing if you want them all to save in the same place. What a
pain. At least it's short; 12 characters including the newline to submit
the entry.

As for your phone and camera it's nice when devices let themselves appear
as USB mass storage to your PC's operating system. Too bad pretty much
nothing from Apple will, nor will most digital cameras (but you can pop
out the memory card and stick it directly in the computer if the computer
speaks SD and recognizes SD cards bigger than 1GB).

Oh, and did I mention that Apple sucks?

I wonder if iTunes works in Wine, or if anyone's hacked up a Linux tool
to access Apple's various iFoos. Without the latter I'm liable to go
Android if I go to a touch-phone-with-apps.

I'm still waiting for a non-evil ebook device to be invented and then
come to my attention. (The iPad? I bet the iTunes EULA starts with
"Abandon hope, ye who enter here". The Kindle? And let Amazon brick my
device or arbitrarily repossess books I bought? Can it even read pdfs of
arbitrary non-big-publisher origin or .txt files or anything, or only
books in some proprietary format from some official app store? Are there
any more choices yet than those two -- preferably with the Kindle e-ink
technology or something comparable? Hell, what I'd really like is an iPad
sized, touchscreen for mouse actions enabled, *computer*, i.e. it runs
the OS of your choice and is basically a PC-compatible laptop with an
iPad-like form factor and a suitable kernel module [or windows .vxd,
blech] for the virtual keyboard functionality. Oh, and supports plugging
in a bog standard physical USB keyboard.)

Keep taking the medicine.

Excuse me?

 

[ClassCastException]

On Mon, 18 Oct 2010 08:46:46 +0100, Tom Anderson wrote:

[massive snip]

Believe me, I've seen worse. And savvy users may not like programs
trying to keep their own documents but that doesn't stop the programs
themselves from trying. These days iTunes is easily the worst
commonly-encountered offender but it's far from the only one.

Recently a friend asked me to help him get his iPhone contacts synching
with his Outlook contacts. Boy was it a pain.

First, there are several places where Windows wants to keep contacts.
Address Book comes with Windows and is one place (and the default iTunes
synch target on Windows); Outlook has its own. Address Book keeps it all
in a single .wab file in C:\Documents and Settings\$USERNAME\Application
Data\Microsoft\Address Book\ (how's that long and deeply nested path
grab you?!) and easily exports to .wab and CSV. iTunes doesn't even let
you *see* the contacts, just synch them(!); the phone does let you see
and edit contacts on the device. Where iTunes and Outlook keep their own
copies I still have no idea. None of them is in My Documents or any of
its subdirectories, though.

The first thing I did was ascertain that iTunes was synching the phone
contacts with Address Book instead of Outlook. I backed up the Address
Book .wab and told it to synch with Outlook instead -- and the Outlook
contacts list, which was missing a bunch of information (basically only
having the names and phone numbers and nothing else), clobbered the
phone's instead of vice versa. Good thing I backed everything up, huh?
So I told it to synch with Address Book again and it clobbered Address
Book. Argh. Restored Address Book's contacts from the backup.

I spent quite a while trying to use the Address Book contacts directly
to replace Outlook's. Address Book speaks wab. Outlook does not. Address
Book exports to CSV, but only the stripped-down data Outlook already had
-- probably how the Outlook contacts got set in the first place, Outlook
was installed and it sucked the Address Book contacts out via CSV during
setup.

Which made me suspect that Outlook was not treating the imported
contacts as last modified whenever they'd been last modified in Address
Book but as last modified when Outlook was installed. So they were
viewed as the newest version by iTunes's synch.

Damn.

Long story short, I manually edited every contact in Address Book --
most of the entries had not had the Gender field set and had an obvious
correct choice for it -- then backed it up again and resynched it with
the iPhone. This restored the iPhone's contacts. Then I synched the
phone with Outlook, and that filled in all the missing data in the
Outlook contacts. Then I left the iTunes on his machine set to synch
with Outlook rather than Address Book.

Problem solved, I think, but it took about two whole hours. If I could
have simply gotten at an outlook.wab in some Outlook subdirectory of My
Documents (or even Application Data) and a phone.wab in some visible,
browseable file directory in the iPhone by browsing the iPhone as a mass
storage device via USB, it would have taken two whole minutes, most of
that watching a file copy dialog reporting its progress.

So what problems have we got here?

1. Everything likes to guard its contacts. Address Book at least leaves
them where a tech-savvy user that has some passing familiarity with
Windows can easily find them. iTunes and Outlook hide them better.
2. Devices that don't provide direct filesystem access via external
tools
suck.
3. Corollary of both 1 and 2: Apple sucks. 4. Applications that have the
same sort of data not being able to share
that data sucks; in particular, Address Book and Outlook only sharing
a limited pidgin vocabulary in common.
5. Corollary of 1 and 4: Microsoft also sucks.

We have had standard vcard and address book formats for years. There
really was no excuse for this.

And even that standard address book format has a problem just by not
being "a directory full of separate vcard files". If it had been, and the
operating system had been anything other than Windows, all the tedious
manual editing could have been replaced by

for f in *.vcf; do touch $f; done

run in the appropriate directory.

Bah!

(Unix isn't 100% immune from that sort of stupidity, of course. It has
mbox format, so none of your "work with a bunch of files" tools are
useful when you want to "work with a bunch of emails". But it's a lot
less prone to it, and it has shell.)

 

[Felix Palmen]

I'm shocked no-one has complained about the excessive requirement
for semicolons. \n should imply end-of-statement unless escaped (\?)

After years of (also) coding vb.net (< 4), I can't believe someone
actually wants that. In version 4, it got (IMHO) even a little more
weird in that you can omit the line end escape (_ in vb) where it's
obvious to the compiler that the statement is not yet complete.

A clear sign for end of statement that doesn't force you to format your
code in a predefined way really is much better.

Regards,
Felix

 

[Felix Palmen]

Thus typedef, from type-def, from type-definition,
is a misnomer. A much better name would be typealias.

This, again, is from the C grammar or compiler view. That's the wrong
way to think about it. The 'typedef' keyword is used by programmers to
define their types and a human being will most of the time define a
thing by giving it a name. Although typedef is not the only way to do
this (struct and enum will also create a name in their special
namespaces), it is ONE possible way and for many the preferred way.
Compilers do not care about natural language semantics of a keyword,
programmers do; 'typealias' would be much less obvious.

Regards,
Felix

 

[Nick]

Typedef can turn a derived type into something that smells like
a primary type.

Thank you. And that's a good enough reason for saying that it defines a
type.

 

[BartC]

After years of (also) coding vb.net (< 4), I can't believe someone
actually wants that.

I've used such a scheme in a language project for many years, and it's
worked very well: although semicolon is generally used as a statement
separator, you have to search hundreds of lines of code to find a single
one.

In this syntax, end-of-line is interpreted as a semi-colon unless the last
symbol on the line was a comma. It uses \ line-continuations to join lines
as in C (and I'm briefly wandering why you need actually \ escapes in C,
outside of macros, since EOL is just white space anyway...)

In version 4, it got (IMHO) even a little more
weird in that you can omit the line end escape (_ in vb) where it's
obvious to the compiler that the statement is not yet complete.

(That's interesting. I'm working on a new project which does just that: an
EOL is a semicolon unless it's obvious (to the programmer) that the last
symbol shouldn't be followed by a semicolon. But I haven't used it enough to
see how well it works, apart from uncovering some corner cases:

if # obviously "if;" would be wrong

end if # "if;" would be OK here

if
a=b # this style won't work unless "if\" was used

The main difficulty I found was in documenting the behaviour...

(Another scheme I came across compared the last symbol on one line, with the
first (significant) symbol on the next, and worked out if there should be a
semicolon in-between. I might have another look...))

A clear sign for end of statement that doesn't force you to format your
code in a predefined way really is much better.

Sure, but 99% of semicolons are completely obvious; so why bother to type
them? And since most code seems to be line-oriented, it's a shame for the
language not to take advantage of that.

 

[BartC]

<snip whole discussion of typedef>

First, I would have you all read:
http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.8

(Or even 21.11.) Any particular bit? Since this stuff on C++ is not very
interesting.

When you write
typedef struct foo bar;
this tells the C compiler about a new type alias.

More like a macro, but a more elaborate one than a textual macro, because of
C's convoluted, inside-out type-specs.

 

[BartC]

(Or even 21.11.) Any particular bit? Since this stuff on C++ is not very
interesting.

Oh, I found it now (the link didn't go straight to 21.11).

But I'll read it later...

 

[BartC]

"Felix Palmen" <[email protected]> wrote in message

[avoiding semicolons]

(That's interesting. I'm working on a new project which does just that... ....
if # obviously "if;" would be wrong ....
if
a=b # this style won't work unless "if\" was used

(Actually that last example *would* work in this scheme. Although I don't
know whether it was worth pointing that out...)

 

[Martin Gregorie]

(Unix isn't 100% immune from that sort of stupidity, of course. It has
mbox format, so none of your "work with a bunch of files" tools are
useful when you want to "work with a bunch of emails". But it's a lot
less prone to it, and it has shell.)

There are mbox -> Mdir format converters around - mboxgrep for one - and
at least almost every MUA can handle one or both those formats and almost
all MTAs can write to those.

If there is a problem with *nix MUAs its the creeping microsoftism called
IMAP, but at least its (usually) safely hidden behind a server such as
Dovecot. If you're really stuck there's always JavaMail, which can read
and write both mbox and Mdir with the appropriate provider plugins as
well as handling the POP3, SMTP and IMAP protocols.

 

[Robert Redelmeier]

After years of (also) coding vb.net (< 4), I can't believe
someone actually wants that. In version 4, it got (IMHO)
even a little more weird in that you can omit the line end
escape (_ in vb) where it's obvious to the compiler that
the statement is not yet complete.

Err ... if whitespace is good, then blackspace is in some sense bad.
Redundencies clutter the code without adding meaning.

A clear sign for end of statement that doesn't force you to
format your code in a predefined way really is much better.

Disagree. Formatting conveys meaning. When you wish to do
something clever, then that too should be flagged (escapes).


-- Robert

 

[Keith Thompson]

Ok.

Here's the thing. Let's say I tell you what I think a word means; I am
*defining* that word. But I'm not *creating* a word -- I'm just telling you
what the word is. (Self-referentially, the word in question would likely be
"define".)

I think... Hmm. Here's the thing. In C, when referring to functions
or variables, it's pretty clear that a declaration tells you that something
exists, and a definition creates it. But in other contexts, a definition
just tells you what something is. I think you're probably applying the
C variables-and-functions sense of "define" here, while I'm just using the
general English sense of "define".

Yes, that's exactly what I'm doing. And personally I think it makes
sense to be consistent about the "define" vs. "declare" distinction, but
it's not really worth arguing about, as long as we understand what we
actually mean. I'll keep that in mind, and I'll probably try to avoid
using the word "define" when it's not clear what it's supposed to mean.

So here's the real point. A typedef does not create a type; it merely
creates a new name for an existing type. The name "typedef" could
easily imply, at least to some people, that "typedef" does create a new
and distinct type, but it doesn't -- at least not on the C language
level.

On the other hand, typedef can be used to create a new "type" that's
*logically* distinct, even if the compiler doesn't see it that way.
For example, size_t might be a typedef for unsigned long in a given
implementation, which means that a size_t object *really is* an
unsigned long object -- but the name "size_t" means something very
different from what the name "unsigned long" means (even aside from
the fact that it might be unsigned int on another implementation.
Similarly FILE might be a typedef for a struct type with an int
member called _fileno, but FILE is *logically* opaque.

As programmers, we often create and use abstractions that aren't
enforced or even understood by the compiler. In the absence of helpful
diagnostics, we just need to maintain enough discipline to avoid
violating these abstractions.

Suppose a new version of the C standard added a "typecreate" keyword
that acts like typedef except that the new type is distinct from the old
one. So, for example:

struct foo { int x; };
typedef struct foo foo1;
typecreate struct foo foo2;

So struct foo and foo1 are different names for the same type, but
foo2 is a distinct type. I'd probably say that typecreate defines
a new type and typedef doesn't. You, I suppose, would say that
typecreate defines and creates a new type, whereas typedef defines
a new type but doesn't create one.

I still don't know whether this covers what Felix Palmen was trying to
say, but since he's decided to plonk me I'm not going to worry about it.

[big snip]