K
Keith Thompson
Nick Keighley said:
On the other hand, there's something to be said for being able look
at a function call and *know* that the arguments won't be modified
(unless it's really a macro invocation).
If you could change the C or C++ or Java syntax, what would you like different?
On the other hand, there's something to be said for being able look
at a function call and *know* that the arguments won't be modified
(unless it's really a macro invocation).
N
Nick Keighley
most other languages manage without it
L
luser- -droog
ACK!
L
luser- -droog
Two faux pas in one night!
That can't be a record, but I am duly repentant.
F
Felix Palmen
* Keith Thompson said:
IBTD. As I already said earlier, new types are /always/ defined by means
of existing ones (at least in any language I know that supports type
definitions). But as soon as the type is more complex than just one
simple builtin type, I don't think "alias" really describes what's going
on.
| typedef struct {
| float speed;
| char *model;
|
| void (*accelerate)(void *this, float delta);
| void (*decelerate)(void *this, float delta);
| } Car;
Would you really call "Car" an alias?
(finally ... a car example
)
B
BartC
Kenny McCormack said:
Now, now. Calm down. Obviously, it won't ever be changed, because C is
what it is.
But the argument, which is valid as far as I can tell, is that the "->"
operator is unnecessary because "." is all you need. I.e., if we were
doing it over from scratch, we could say that whenever we see:
something.member
and the compiler can determine that something is a pointer, then it
would internally convert it to:
something -> member
Since C is a statically typed language, this should work.[/QUOTE]
It means that given the following defs:
struct pt {int x,y,z;} v = {2708,2716,2732};
struct pt* p=&v;
struct pt** q=&p;
struct pt*** r=&q;
then currently, to access the .y coordinate using only ".", each of these
variables in turn requires:
v.y;
(*p).y;
(**q).y;
(***r).y;
Using "->", this simplifies (?) to:
v.y;
p->y;
(*q)->y;
(**r)->y;
So "->" only really helps when there is a single level of indirection.
The proposal to allow "." to dereference pointers /I think/ would allow:
v.y;
p.y;
q.y;
r.y;
Ie. dereferencing, no matter how many levels, would be completely
transparent (but in a similar manner to array indexing).
If the proposal is for it to only work for one level, then I don't know what
the pattern would look like for multiple indirection.
Actually I'm warming to the idea of using solely ".", but only because C has
an otherwise ugly syntax when progressing between 0, 1 and N levels of
indirection (using 2 different forms when only "." is used, and 3 different
forms when "->" is used). (Unlike, say, Pascal, where you just have N
consecutive "^" symbols; very neat.)
K
Keith Thompson
IBTD. As I already said earlier, new types are /always/ defined by means
of existing ones (at least in any language I know that supports type
definitions). But as soon as the type is more complex than just one
simple builtin type, I don't think "alias" really describes what's going
on.
| typedef struct {
| float speed;
| char *model;
|
| void (*accelerate)(void *this, float delta);
| void (*decelerate)(void *this, float delta);
| } Car;
Would you really call "Car" an alias?
(finally ... a car example
Yes, the name "Car" (created by the typedef) is nothing more than an
alias for the type "struct { ... }".
If you had left out the typedef keyword and the name "Car":
struct {
float speed;
char *model;
void (*accelerate)(void *this, float delta);
void (*decelerate)(void *this, float delta);
};
then you would have defined a new type, exactly the same type that was
defined by your original declaration. The only difference is that
the "struct { ... };" form does not additionally create an alias
"Car" for that type.
It might be simpler to use an example where the struct has a tag. This:
typedef struct car {
/* ... */
} Car;
is equivalent to this:
struct car {
/* ... */
};
typedef struct car Car;
In both cases, we create a new type called "struct car", and then
an alias for the same type called "Car".
Your original example doesn't give a name to the created type,
but that's the only difference.
F
Felix Palmen
* Keith Thompson said:
No. You cannot sensibly argument that a notation of "struct { ... }"
identifies a type -- it describes it. The description may be
unambiguous, so it would be possible to describe the type each and every
time you need it, but for /defining/ a type, it should get its own
identifier -- just like defining a function, a variable, etc.
Another way to do it, this way you define a type called "struct car" --
one of the peculiarities of C I don't like. You need to use typedef if
you want to define your type in the "global" identifier namespace. But
at least, that's the reason typedef is perfectly sensible named, IMO.
It does, the name is "Car" (as opposed to "struct car"). Of course, if
you give it both names, one is obviously an alias for the other.
Regards,
Felix
N
Nick
Keith Thompson said:
I think this is all about how you use words, again. In one sense it
does define a type. Particularly when used for things other than
structures.
What it does is it gives you a token that can then be used as the name
of a type. In a sense, C starts off with int, char and the like.
If you do typedef like:
typedef char *(* FUNCT)(int *[]);
then in a sense you have now added FUNCT as a type to C - functions
taking an array of integer pointers and returning a character pointer.
You can now use it just the way you would use "int" alone.
I think as the language as evolved and got standardised, we've shifted
the meaning of type to a slightly different meaning - one in which
"struct fred *" is as much a type as "char" is. But I think there was a
logic behind the meaning, and I think saying it doesn't "define a type"
is possibly confusing for some.
I say that because to me, when I first encountered typedef, it was quite
clear what it did. It defined a new "high level" type that you could
use just like the built in ones.
Wholehearted agreement here.
T
Tom Anderson
You should come and see mine. Nothing special, bog-standard Fedora 13,
which follows big-standard unix filesystem layout. I have a home
directory, in that i have subdirectories for different sorts of things
(Documents, Pictures, Music, Code), in those i have subdirectories for
projects, and in those i have files. A typical absolute path:
/home/tom/Code/ProspaceFile/ProspaceBuilder.java
Doesn't seem ludicrously long to me. Especially given that the /home/tom
is often implicit.
Things that aren't my documents can live in other places. For instance,
javac is at:
/usr/bin/javac
As are almost all the other programs i've installed with the package
manager. Some things i've installed myself are slightly deeper; for
example, the OpenJPA javadoc is at:
/usr/local/share/doc/apache-openjpa-2.0.1/javadoc/index.html
Even that isn't that long, really. I certainly don't have trouble
navigating. I know:
* My stuff is in /home/tom/${appropriate subdirectory}
* System stuff is in /bin, /sbin, /etc, /lib, /var and so on
* Package-managed stuff is in /usr (/usr/bin, /usr/lib etc), and also /etc
and /var
* System-wide stuff i've installed by hand is in /usr/local, except for
some of it which is in /opt
There are some more obscure things, and Chrome goes in /opt despite being
package-managed, but that's 99% of what i need to know.
If something is package-managed, i can ask the package manager about it.
If i know the filename but not the location, i can ask locate.
True. But the package manager knows where they are (barring ~/.*,
generally), and mostly, i don't care.
Yeah, that doesn't tend to happen to me. It also didn't tend to happen to
me when i used Windows, from what i recall.
No, because you just don't organise by program. That's a dumb idea which
went out some time in the late 80s.
Do they? I don't recall any programs i used on Windows doing that.
So keep your project folders in My Documents. Even if Windows dumps you
there rather than the last folder you used or whatever, your destination
is a few clicks away.
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.
Keep taking the medicine.
tom
M
Michael Foukarakis
I don't understand what you mean by "real world". In case you mean
"outside of programming" (i.e. mathematics) you are right. 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".
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. Whether those that don't should be
accomodated, I don't really care for that discussion (yet).
M
Michael Foukarakis
As is everyone else, I'm sure.
Right. In my opinion, both '=' and ':=' differ by one character from
'==' (oh god, that levenshtein distance function is taking hold of my
brain..), and for me it would be just as distinct if we exclude
mistypes from the equation (no pun intended).
K
Keith Thompson
Not all C types have simple names; in fact most of them don't. We have
int, short, and char, but we also have long double, unsigned long long
int, char*, int[42], and struct { int x; double y; }.
To take a simpler example:
typedef int arr[10];
This declaration makes "arr" an alias for the existing type
"int[10]", a type that otherwise wouldn't have a name of its own
other than "int[10]". Consider:
typedef int word;
typedef int arr[10];
typedef struct { /* ... */ } Car;
All three of these create an alias for an existing type. The only
difference is complexity and the fact that, in at least the third
case, the type is created by the declaration (and would have been
created even without the "typedef" keyword and the "Car" identifier).
typedef is the *only* way that a type can have a name that's a single
identifier (as opposed to a keyword).
A digression: Many programmers (including me) prefer *not* to use
typedefs for structs. I'd just declare
struct car {
/* ... */
};
and then refer to the type as "struct car". The type already has
a perfectly good name; it doesn't need another one.
But if you dislike having to repeat the "struct" keyword every time you
refer to the type, you can use a typedef, and even omit the tag if you
don't need to refer to the type name inside its declaration. Keep in
mind that you can use the same identifier for the tag and the typedef.
End of digression.
And if you don't give it both names, then "Car" is an alias for
an anonymous struct type.
K
Keith Thompson
Another couple of points:
You can certainly argue that something that defines a type (such as a
struct declaration) *should* create an identifier for it, but the fact
is that, in C, it doesn't. It usually doesn't make sense to create
a struct type without creating a name for it, either a tag or a typedef
name, but it's perfectly legal. For example, you can write:
struct { int x; int y; } obj;
and refer to obj.x and obj.y, but you've provided no way to refer to the
type of obj. If you want that type to have its own name, you need to
give it one. The same applies to union and enum types.
Finally, something I should have written earlier, a quote from the C
standard. C99 6.7.7p3:
A typedef declaration does not introduce a new type, only a
synonym for the type so specified.
[...]
K
Keith Thompson
Nick said:
Perhaps the word on whose definition we disagree is "define".
To define something is to *create* it. If you define a type,
then you have a type that would not have existed if you hadn't
defined it. This is in contrast to "declaring" something; a
declaration can assert that something exists without creating it
(such as an extern object declaration).
Right, it gives you a *name*. It defines that name (an identifier).
It doesn't define a type; the type already existed (if it didn't,
the typedef declaration wouldn't be able to refer to it).
Or you could omit the typedef and use *the same type* directly:
void foo(char *(* argument)(int *[]));
The typedef is certainly convenient, but you can almost always get
by without it by referring to the original type. (For syntactic
reasons, you'd need a typedef to use this type with the va_arg()
macro.)
"struct fred *" has always been as much a type as "char" is.
I understand that saying typedef doesn't define a type may be
confusing for some. But it's the truth: typedef doesn't define
a type.
Ok, but did you understand that this "new" type isn't distinct
from the original type? Did you understand that, given:
typedef int word;
"int" and "word" are quite literally *the same type*?
[...]
F
Felix Palmen
* Keith Thompson said:
Well, as this applies to nearly anything you have written in response,
I'll just put it here:
You can either pretend you're a compiler and don't know anything more
abstract than your grammar (and the standard defining it) -- or you can
just apply some human abstraction to understand the /intention/ behind
C's language constructs and ask yourself in that context whether typedef
is a good name or not.
My decision is clear: the name is perfect.
Regards,
Felix
F
Felix Palmen
* Keith Thompson said:
Oh and by the way .. even a standard can have some controversial points.
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;
Regards,
Felix
A
August Karlstrom
Pascal, Modula-2, Oberon, Ada and Eiffel comes to mind.
Whichever way you cut the mustard, we still need a symbol to test for
equality and what would be more natural than to use a symbol which has
already been in use for several hundred years (invented in 1557 by
Welshman Robert Recorde).
/August
S
Seebs
I don't quite agree. Doubled characters are easier to miss than other
added characters, in general. Especially when the symbol is just "two
parallel lines", and all the extra character does is make them longer.
It's similarly easier to get confused by, say, _ vs. __ in the middle
of a long name, than it would be by _ vs. #_.
-s
K
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.