why use -> (not .) with pointers?

[Richard Tobin]

No, you just have rules for which contexts they get "deprocedured" in,
as in Algol68 for example.

[/QUOTE]

Please show us an example of this, where f is a function returning a
function of the same type as f.

I'm not sure such a thing can be declared in Algol68 any more than
it can in C.

-- Richard

 

[Tydr Schnubbis]

I did, and you're not my friend. The statement in K&R refers to x->y
as "convenient shorthand", which was how I described it. Or you can
call it "syntactic sugar" if you like. The early compilers built a
parse tree for code generation that was not likely to preserve any
difference between x->y and (*x).y. IME, they generated *exactly*
the same code (and pretty good code at that, in the case of Ritchie's
compiler) for either form.

Yes, noone has disputed the 'syntactic sugar' part.

If you're still not sure what I disagree with, reread the above,
my fellow poster.

Just to make it clear, there are two issues here:

#1) s->x is a shorthand for (*s).x

#2) early compilers used the difference between s->x and s.x to know
whether to generate code using indirect or direct addressing

(e-mail address removed) was stating #2 as a fact. Lew Pitcher, thinking
he instead was disputing #1, replied rather harshly. I think everyone
can see that he misread the post he replied to. They are talking about
two different, but related aspects of the C syntax.

I sometimes misread posts, too. But I still haven't had the 'pleasure'
of people supporting me even when I'm wrong. This discussion is getting
a bit childish now, which I'll be the first to admit.

 

[Tydr Schnubbis]

A says "I don't think foo" and "I think bar", while B says "I think
the opposite", and you are having trouble telling who disagrees
with what!!! I suspect you are in the wrong field.

I was trying to be polite. Being more direct is sometimes a bit on the
offensive side. But the idea is they were talking about two different
things, so they didn't really seem disagree at all. Can happen to
anyone, including myself. I have explained in a reply to plauger.

 

[icub3d]

C is a language and therefore must have rules. In English we say A
book and AN elephant. It may be easier on our part to just use A in
both cases, but that's not so.

I think more than anything -> helps us as programmers remember that we
are dealing with a pointer to a struct and not the struct itself. Sure
the compiler could figure it out, but it may be difficult for us to
figure it out. Why? Because we are allowing . to mean two different
things. Making a distinction helps us more than the program. It all
turns into 1's and 0's after all and . and -> don't have much meaning
to the processor

 

[Me]

Letting the compiler "guess" what you mean is a really, really bad idea

So would you favour having different operators for integer and
floating-point addition?

No, but I might favor not being able to implicitly convert between one
and the other. Ditto for char/enums to/from integers and _Bool to other
types.

Is it a disaster that if foo is a function
pointer you can say foo(1) instead of (*foo)(1)?

Yes, the second form should be eliminated from the language IMHO.
Function names decompose to regular pointers the same way that arrays
of T decompose to pointers to T (but even worse) so you can do:

(*&******&*****printf)("hi");

if you really wanted to. The () on the rhs is the thing that does the
dereference the same way that [] on a pointer does a dereference.

Why is determining the action "guessing" in this case but not the
others?

Using . because there is no ambiguity hides a dereference when there
really is one. Like keeping track of pointers in code wasn't hard
enough.

 

[Me]

when accessing the variables in a struct: What's the reason why in C

you have -> and . instead of only . ?

Convienience and consistency.

a->b->c

is a shortcut for

(*(*a).b).c

If you let that expression be expressed as:

a.b.c

due to the lack of ambiguity, it makes it look like the pointer gets
auto dereferenced which is *really* crappy from a grep and a code
reading standpoint. Also imagine the case where 'a' was a pointer to a
pointer:

(*a).b.c

would be a shortcut for:

(**a).b.c

Which seems like a really insane thing to do just because there is no
ambiguity. Other languages don't have this problem because you can't
create pointers to pointers and their types are automatically
dereferenced. But these languages have an ambiguity with assignment
(assuming they're imperative languages) so they need a way to
distinguish between reseating a pointer and making a copy of a value.

 

[REH]

Convienience and consistency.

a->b->c

is a shortcut for

(*(*a).b).c

If you let that expression be expressed as:

a.b.c

due to the lack of ambiguity, it makes it look like the pointer gets
auto dereferenced which is *really* crappy from a grep and a code
reading standpoint. Also imagine the case where 'a' was a pointer to a
pointer:

(*a).b.c

would be a shortcut for:

(**a).b.c

Which seems like a really insane thing to do just because there is no
ambiguity. Other languages don't have this problem because you can't
create pointers to pointers and their types are automatically
dereferenced. But these languages have an ambiguity with assignment
(assuming they're imperative languages) so they need a way to
distinguish between reseating a pointer and making a copy of a value.

Explain to me how Ada, which allows pointers to pointers, doesn't
automatically dereference, only used . (not ->), and is an imperative
language, has any ambiguity with assignment (hint: it doesn't).

REH

 

[Me]

Other languages don't have this problem because you can't

Explain to me how Ada, which allows pointers to pointers, doesn't
automatically dereference, only used . (not ->), and is an imperative
language, has any ambiguity with assignment (hint: it doesn't).

I think you already explained it yourself. I said in languages that
don't allow pointers to pointers and that automatically dereference
have this ambiguity. I don't really mean ambiguity in a strict sense, I
mean it in that they need a way to distinguish between reseating a
pointer and making a copy somehow. It could be something as trivial as:

// explicitly making a copy
a = b; // this does a reseat
a = copy(b); // reseats but creates a copy first

or

// two different operators
a = b; // copies value
a := b; // reseat

which isn't really that profound as reseating and copying values are
basic operations in any useful imperative language. The worst are
languages that provide primitive types using value semantics and UDTs
using reference semantics and hiding it behind copy on write. It's very
easy to come up with examples that show inconsistencies in their type
system but I'm already getting way off topic here.

 

[lawrence.jones]

Well, not *any* value. Early C was quick to convert an integer to
a pointer, which is what is required here. I'm not sure it tolerated
a float here, and it certainly didn't tolerate a struct.

On the other hand, I seem to recall that the "." operator would, indeed,
take *any* lvalue on the left. Does that match your recollection?

-Larry Jones

I think football is a sport the way ducks think hunting is a sport. -- Calvin

 

[P.J. Plauger]

On the other hand, I seem to recall that the "." operator would, indeed,
take *any* lvalue on the left. Does that match your recollection?

Could be. Early C was pretty wild and wooly.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[lawrence.jones]

Could be. Early C was pretty wild and wooly.

Which makes sense as far as types are concerned since it was derived
from B, which was essentially typeless.

-Larry Jones

We don't ATTEND parties, we just CRASH 'em. -- Calvin

 

[Kenny McCormack]

Just to make it clear, there are two issues here:

#1) s->x is a shorthand for (*s).x

#2) early compilers used the difference between s->x and s.x to know
whether to generate code using indirect or direct addressing

(e-mail address removed) was stating #2 as a fact. Lew Pitcher, thinking
he instead was disputing #1, replied rather harshly. I think everyone
can see that he misread the post he replied to. They are talking about
two different, but related aspects of the C syntax.

I sometimes misread posts, too. But I still haven't had the 'pleasure'
of people supporting me even when I'm wrong. This discussion is getting
a bit childish now, which I'll be the first to admit.

Meta-discussion follows.

The problem with Usenet (as with the world at large) is that 75% of the
traffic is newbies (stupidly) asserting things that are clearly wrong, such
as that (for example), . and -> mean the same thing (which was the implicit
subtext of the original post). So, we spend a lot of time correcting them.

However, with the remaining 25%, which is (or should be - but please accept
this for the sake of discussion) reasonably well-informed people saying
reasonably well-informed things, the problem is that we spend 90% of our
time convincing each other that we're not in the 75%. That the default
assumption is that we are (since most of the posters, taken as a group, are)
is what led to the above misunderstanding.

 

[Tydr Schnubbis]

The problem with Usenet (as with the world at large) is that 75% of the
traffic is newbies (stupidly) asserting things that are clearly wrong, such
as that (for example), . and -> mean the same thing (which was the implicit
subtext of the original post). So, we spend a lot of time correcting them.

However, with the remaining 25%, which is (or should be - but please accept
this for the sake of discussion) reasonably well-informed people saying
reasonably well-informed things, the problem is that we spend 90% of our
time convincing each other that we're not in the 75%. That the default
assumption is that we are (since most of the posters, taken as a group, are)
is what led to the above misunderstanding.

I'm glad to get some support here. It may well be that my understanding
of the English language is inadequate. But it seems to me the original
poster understands that '.' and '->' have different meanings. It's just
that he's seen other languages that use the dot for both. Like Java,
which uses the dot notation for both reference and value semantics. But
anyway, I bet he's amused to see what he's stirred up...

 

[Dave Thompson]

I think you already explained it yourself. I said in languages that
don't allow pointers to pointers and that automatically dereference
have this ambiguity. I don't really mean ambiguity in a strict sense, I
mean it in that they need a way to distinguish between reseating a
pointer and making a copy somehow. <snip>

I think you've confused yourself with the negatives. It's if you DO
have pointer to pointer and DO automatically dereference -- in
particular, an LHS -- that you (may) have an issue, as in algol.

Ada does have pointer to pointer (under another name) and dereferences
in many cases but not an LHS.

Fortran doesn't have pointer to pointer, and dereferences the pointers
it does have (since F90) everywhere including LHS but uses a distinct
syntax for reseat. C++ dereferences references everywhere but doesn't
reseat at all.

- David.Thompson1 at worldnet.att.net