why use -> (not .) with pointers?

S

sandeep

Hi,

when accessing the variables in a struct: What's the reason why in C
you have -> and . instead of only . ? Are there cases in which the
compiler couldn't figure out what to do? The problems are
1) extra typing
2) inconsistency with other languages Java, Ruby etc.
(obviously Java came later but it would be good to converge to standard
usage for accessing members)
 
K

Kenny McCormack

Hi,

when accessing the variables in a struct: What's the reason why in C
you have -> and . instead of only . ? Are there cases in which the
compiler couldn't figure out what to do? The problems are
1) extra typing
2) inconsistency with other languages Java, Ruby etc.
(obviously Java came later but it would be good to converge to standard
usage for accessing members)

This gets discussed every so often. The basic answer is: It is what it is.

Of course, any implication that C should be changed to be like other
languages (your "Java, Ruby, etc") will be met with snickers at best by
the regs.

--
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.
 
L

Lew Pitcher

This gets discussed every so often. The basic answer is: It is what it
is.

Of course, any implication that C should be changed to be like other
languages (your "Java, Ruby, etc") will be met with snickers at best by
the regs.

Not at all. Even the regs agree that C should look like other languages.
They just don't agree on /which/ other language C should look like.

Personally, I favour COBOL. I look forward to the day when, instead of
a.b
I can use
b OF a
(as in
MOVE b OF a TO b OF c.
instead of
c.b = a.b;

OTOH, if C "looked like" some other language, what would the benefit be?
After all, if you wanted to write code in that "other language", why would
you write it in C? And why would you choose that "other language" when C
looks exactly like it?

For that matter, if C looked like some other language, how would you tell
the two languages apart? Wouldn't that /make/ C into the other language?
 
B

BGB / cr88192

sandeep said:
Hi,

when accessing the variables in a struct: What's the reason why in C
you have -> and . instead of only . ? Are there cases in which the
compiler couldn't figure out what to do? The problems are
1) extra typing
2) inconsistency with other languages Java, Ruby etc.
(obviously Java came later but it would be good to converge to standard
usage for accessing members)

it is because the standards say it is, and there was probably some
historical reason...

granted, some of us have written compilers where we were too lazy to bother
to distinguish them (for example, in mine they are generally treated as
equivalent), but to really be proper they need to be distinguished (if for
little other reason than to complain when they are used with the wrong type
of object...).

or such...
 
L

lawrence.jones

sandeep said:
when accessing the variables in a struct: What's the reason why in C
you have -> and . instead of only . ?

Because they do different things.
Are there cases in which the compiler couldn't figure out what to do?

Not anymore, but there were when C was first defined and there's never
been any compelling reason to change things.
 
S

Seebs

when accessing the variables in a struct: What's the reason why in C
you have -> and . instead of only . ? Are there cases in which the
compiler couldn't figure out what to do?

Probably not, but there is noticable benefit to being able to tell
whether you are working with the object itself or a pointer to it, at a
glance.
1) extra typing

Not significantly so.
2) inconsistency with other languages Java, Ruby etc.
(obviously Java came later but it would be good to converge to standard
usage for accessing members)

No, it wouldn't, because changing the existing syntax is unlikely to be
rewarding.

But I give up. You consistently harass, insult, and attack people, you make
up crazy stuff, you get things wrong that would be impossible to get wrong if
you were actually as stupid as you pretend to be. You have not contributed
to discussion of C, even though your posts initially appear topical, because
you respond to any attempt to induce more productive behavior with hostility
and deeply irrational behaviors.

It seems implausible that you are actually a newbie who wants to learn C;
more likely (especially given your posting history, host, etcetra), you're
just another bored troll.

Bye.

-s
 
T

Tim Harig

when accessing the variables in a struct: What's the reason why in C
you have -> and . instead of only . ? Are there cases in which the
compiler couldn't figure out what to do? The problems are

Basically, using -> tends to be clearer. Its a very visual indication that
you are using a pointer to dereference a part of a structure.

#include <stdio.h>

struct my_struct {
int member;
};

int main(int argc, char **argv) {

struct my_struct my_struct_instance;
struct my_struct* my_struct_pointer = &my_struct_instance;

/* which looks clearer to you? This... */
my_struct_pointer->member = 2;
printf("%d\n", my_struct_pointer->member);

/* ...or this */
(*my_struct_pointer).member = 4;
printf("%d\n", (*my_struct_pointer).member);

return 0;

}

Note that both statements are equivilant; but, one is more viserally
appealing then the other. The second statement becomes even worse when
extra dereferencing and casting are used. This entails a lot of
parenthesis that most be nested correctly or the code changes meaning or
presidence. -> however, tends to work pretty intuitively in these
conditions.

It can be godsend when creating generic data structures where you reference
a member of a structure that is a void* that must be cast to another
structure, so that you can reference a member of the substructure. -> does
this pretty easily by just chaining together; but, dereferencing the
members manually adds enough extra clutter to make the references a
little overwhelming.
1) extra typing
2) inconsistency with other languages Java, Ruby etc.
(obviously Java came later but it would be good to converge to standard
usage for accessing members)

I thought Java (and probably Ruby as Python does) had references instead
of pointers?
 
K

Keith Thompson

sandeep said:
when accessing the variables in a struct: What's the reason why in C
you have -> and . instead of only . ? Are there cases in which the
compiler couldn't figure out what to do? The problems are
1) extra typing

Not a significant problem.
2) inconsistency with other languages Java, Ruby etc.
(obviously Java came later but it would be good to converge to standard
usage for accessing members)

Why would that be good?

The reasons for the "." and "->" operators being spelled differently
is largely historical. Very early versions of C were (even) less
strongly typed than modern C, and I think there were cases that
could have been ambiguous, though there are no such cases anymore.
It might also have been helpful to primitive (by modern standards)
compilers.

As for why it hasn't been changed, there just aren't any really
good reasons to do so. When reading code, seeing x->y vs. x.y tells
you whether x is a pointer or a struct (or union) without having to
look at the declaration; that's not a huge advantage, but it's well
worth the trivial extra typing. It's particularly important in C
to know what is and isn't a pointer (look at the array-vs-pointer
confusion). And suppose C201X introduced "." as a synonym for "->".
That wouldn't change the millions or billions of lines of code that
currently use "->" (and no, removing "->" from the language would not
be an option). New code using "." on pointers would not compile on
old compilers, and would inevitably be mixed with code that continues
to use "->". It would be tremendously costly with no real benefit.

In deciding whether a language should have a given feature, there's
a *tremendous* difference between inventing a new language from
scratch (where you can do what you like as long as it's consistent)
and revising an existing language (where existing code is the most
important consideration).
 
E

Ed

sandeep said:
Hi,

when accessing the variables in a struct: What's the reason why in C
you have -> and . instead of only . ?

1) Bad language engineering.
2) Bad language engineers.
3) The bad "programming language technology mantra": compatibility back,
even to known wrongness, is valued.
4) Job security.
5) 3 above.
6) Can't teach (an) old dog(s) new tricks (right, C-Language defenders?).
7) Massochism.

;)

Yes, just a dot is decidedly better, but can't be had with C because the
spec for C was carved on two tablets by the hand of God and thrown by
Moses at the people when they were found to have lost their faith,
fornication... Oh, nevermind.
 
E

Ed

Kenny McCormack said:
This gets discussed every so often. The basic answer is: It is what it
is.

I'd say it's a desireable trait of a language. Of course though, it
cannot be had with C (like MANY other things cannot also). To put a
facade on a trailer that looks like a mansion is, well, it would be
hokey! (Not that living in a trailer is BAD: I live with my parents!
Ewwww! Anyone know of a GIRL who needs a roommate? Mating would be
strictly optional, but I would want to have guests sleep over
occassionally if it was just a room but not a mate situation).

Live! From NY. It's Saturday night! :)

Of course, any implication that C should be changed to be like other
languages (your "Java, Ruby, etc") will be met with snickers at best by
the regs.

Cuttin' him off at the pass huh. I don't think he was implying that. I
think he was basically askin: "Why is this lame syntax in C?", or
something similar. Surely the -> thing is the LEAST of C's negatives.
Surely the primary thing is that C is unreliable and not suitable for
large-scale software development.
 
E

Ed

Because they do different things.


Not anymore, but there were when C was first defined and there's never
been any compelling reason to change things.

You mean, what's the point when closer to death than to birth?
 
A

Alan Curry

Yes, just a dot is decidedly better, but can't be had with C because the
spec for C was carved on two tablets by the hand of God and thrown by

How about this for a reason: if it acts different, it should look different.
Dereferencing is different from not-dereferencing.

You found a pair of operations that could be represented by a single symbol,
since there's no set of operands that is legal for both. Does this mean it's
a good idea? No. Representing different operations with the same symbol is
called "overloading", and C is not a very overloaded language.

The arithmetic operators are pretty heavily overloaded, and this does cause
problems. Integer division gets used accidentally where floating point
division was intended. Pointer addition gets done with the wrong value
because people forget that it's automatically scaled up by the sizeof the
target.

'.' and '->' are the opposite of overloaded. They're underloaded. At any
particular spot in a program, at most one of them is legal. The distinction
between them is a pure redundancy. And redundancy is good. Redundancy allows
us to assign a meaning to only some inputs, and reject the others.

The elimination of redundancy makes more inputs meaningful, which makes the
language more delicate. It's helpful to have a lot of meaningless inputs that
near the meaningful ones, because meaningless inputs are errors detected at
compile time.

Hooray for redundancy! Hooray for meaninglessness! Hooray for underloading!
 
S

sandeep

Seebs said:
Probably not, but there is noticable benefit to being able to tell
whether you are working with the object itself or a pointer to it, at a
glance.

I don't really see any benefit. You need to know the type of a variable
to understand what it's doing anyway.
But I give up. You consistently harass, insult, and attack people, you
make up crazy stuff, you get things wrong that would be impossible to
get wrong if you were actually as stupid as you pretend to be. You have
not contributed to discussion of C, even though your posts initially
appear topical, because you respond to any attempt to induce more
productive behavior with hostility and deeply irrational behaviors.

I really don't see how anyone is attacking anyone here except for you
attacking me.

It is true that I pointed out a mistake made by Mr Heathfield and I'm
sorry if that insulted people because I'm new here, but I didn't do it as
an attack.

I also try to remember to cut signatures now even though it's difficult
to remember every time, because people asked me to.
It seems implausible that you are actually a newbie who wants to learn
C; more likely (especially given your posting history, host, etcetra),
you're just another bored troll.

I am not a newbie, I would describe myself as a C semi-expert. I have a
computer science degree and now I am doing a masters course where I am
specializing in C. I see that there are lots of real experts in this
group and I hope I will be able to learn from them.
 
B

bart.c

sandeep said:
Hi,

when accessing the variables in a struct: What's the reason why in C
you have -> and . instead of only . ? Are there cases in which the
compiler couldn't figure out what to do? The problems are
1) extra typing
2) inconsistency with other languages Java, Ruby etc.
(obviously Java came later but it would be good to converge to standard
usage for accessing members)

Given:

point p = {10,20,30};
point *q = &p;
point **r = &q;
point ***s = &r;

the way to dereference these would be something like:

printf("p.y = %d\n",p.y);
printf("q.y = %d\n",(*q).y);
printf("r.y = %d\n",(**r).y);
printf("s.y = %d\n",(***s).y);

Notice the pattern emerging. Now introduce "->", and the pattern looks like:

printf("p.y = %d\n",p.y);
printf("q.y = %d\n",q->y);
printf("r.y = %d\n",(*r)->y);
printf("s.y = %d\n",(**s)->y);

So not quite so orthogonal. Now what would this look like if "." and "->"
were interchangeable?

Either:

printf("p.y = %d\n",p.y);
printf("q.y = %d\n",q.y);
printf("r.y = %d\n",(*r).y);
printf("s.y = %d\n",(**s).y);

in which case this doesn't buy you much in the general case (but matches how
arrays work, where 0 or 1 levels of indirection have the same syntax; more
need extra derefs); or:

printf("p.y = %d\n",p.y);
printf("q.y = %d\n",q.y);
printf("r.y = %d\n",r.y);
printf("s.y = %d\n",s.y);

which is certainly neater, but having "s.y" hiding 3 levels of indirection
would introduce it's own problems I think.

(And would no match the way arrays work, by having all indirection levels
have the same syntax instead of just 0 and 1 levels. I wasn't able to check
function indirection because I can never remember the syntax for function
pointers; if new syntax is called for, that might be a better place to
start...))

One problem is that "->" is quite an ugly, bolted-on construct and does not
really follow on from the ".". Using Pascal syntax for "." and "->", my
example would look like:

printf("p.y = %d\n",p.y);
printf("q.y = %d\n",q^.y);
printf("r.y = %d\n",r^^.y);
printf("s.y = %d\n",s^^^.y);

which I think is an improvement on any of the C variations, existing or
planned: looks reasonable and gives the important distinction between the
values.
 
B

blmblm

[ snip ]
I thought Java (and probably Ruby as Python does) had references instead
of pointers?

I can't say about Ruby, but what Java has -- well, they're called
references, but I think it makes sense to think of them as "safe(r)
pointers", since in some sense that's what they are -- they point
to things, but you can't do arithmetic or other "unsafe" operations
on them. (The fact that what you get when you try to dereference
one that's null is a NullPointerException supports this view,
in my thinking.) But that's not the whole story ....

Java has two broad categories of variables, "primitive types"
(such as int and float) and "reference types" (loosely speaking,
pointers to objects). It's not possible to declare a variable that
points to a primitive type, nor is it possible to declare a variable
that *is* an object (as it is in C++, which allows variables that
*are* objects as well as variables that *point to* objects).

Getting back, sort of, to the topic at hand, in Java one might
write

Foo f = new Foo();
f.x = 10;

to assign a value of 10 to a field in the object *pointed to*
by f. As far as I know, the syntax "f->x" isn't valid Java.
 
S

SG

[...]
As for why it hasn't been changed, there just aren't any really
good reasons to do so.  When reading code, seeing x->y vs. x.y tells
you whether x is a pointer or a struct (or union) without having to
look at the declaration; that's not a huge advantage, but it's well
worth the trivial extra typing.

Agreed.

If C were to introduce . as an alias for -> in cases where the left
hand side is a pointer, I guess the C++ folks wouldn't be too happy
about this. Right now, they can create pointer-like objects ("smart
pointers") by overloading operators * and ->. The dot operator can't
be overloaded in C++ and this is unlikely to change. I think it's more
important to keep C and C++ from diverging too much than to alter C so
it "looks like some other languates".

Another reason has also been mentioned. In languages like Java there
is simply no need to distinguish between . and -> because the left
hand side is _always_ a reference. In C# they introduced "value types"
in addition. But since you cannot point to objects of a "value types"
there is again little need to distinguish between . and -> -- unlike
in C and C++.

I would go as far as saying that altering C in that way would only
confuse people because it unnecessarily blurs the line between direct
and indirect access.

Cheers!
SG
 
B

Ben Bacarisse

Keith Thompson said:
The reasons for the "." and "->" operators being spelled differently
is largely historical. Very early versions of C were (even) less
strongly typed than modern C, and I think there were cases that
could have been ambiguous, though there are no such cases anymore.

Yes, merging . and -> would have removed a significant distinction in
early C. The expression before a . had to be an lvalue but it did not
have to of structure type. And the expression before -> could be any
primary expression of what we'd now call scalar type. So given

struct { char msb, lsb; } *p;
int a;

I think one could write:

a->lsb = 1; /* set the byte at offset 1 from the address in a */
a.msb = 1; /* set one byte of a */
p->msb = 0; /* as today */
p.lsb = 0; /* change the pointer by setting a part of it */

I.e. there were contexts in which both a.x and a->x were legal and meant
different things.

[I say "think" because this is pre-K&R and I don't recall ever seeing
such a compiler.]

As for why it hasn't been changed, there just aren't any really
good reasons to do so. When reading code, seeing x->y vs. x.y tells
you whether x is a pointer or a struct (or union) without having to
look at the declaration; that's not a huge advantage, but it's well
worth the trivial extra typing. It's particularly important in C
to know what is and isn't a pointer (look at the array-vs-pointer
confusion).

Agreed. I find the distinction introduced by . and -> to be helpful
when reading code.
And suppose C201X introduced "." as a synonym for "->".
That wouldn't change the millions or billions of lines of code that
currently use "->" (and no, removing "->" from the language would not
be an option). New code using "." on pointers would not compile on
old compilers, and would inevitably be mixed with code that continues
to use "->". It would be tremendously costly with no real benefit.

I don't see the cost, at least not any tremendous cost. Do you mean
there would be a large cost from the loss of clarity in new code?

<snip>
 
B

BGB / cr88192

Ed said:
I'd say it's a desireable trait of a language. Of course though, it cannot
be had with C (like MANY other things cannot also). To put a facade on a
trailer that looks like a mansion is, well, it would be hokey! (Not that
living in a trailer is BAD: I live with my parents! Ewwww! Anyone know of
a GIRL who needs a roommate? Mating would be strictly optional, but I
would want to have guests sleep over occassionally if it was just a room
but not a mate situation).

Live! From NY. It's Saturday night! :)

I suspect many people have mate-finding problems...

admittedly though, I personally believe that premarital abstinence is a
moral obligation, and so live under this requirement.

Cuttin' him off at the pass huh. I don't think he was implying that. I
think he was basically askin: "Why is this lame syntax in C?", or
something similar. Surely the -> thing is the LEAST of C's negatives.
Surely the primary thing is that C is unreliable and not suitable for
large-scale software development.

C works fine for large-scale apps.
there are many multi-Mloc programs in C, and nearly all other non-C
languages build on a C-based foundation.

actually, in terms of app scalability, C is probably one of the most
scalable languages I know of as well, as there are no arbitrary limits
hindering app size or complexity.


granted, one can't really do a large app following the same conventions as a
smaller app (otherwise one ends up with something terrible), but things like
maintaining modularity and abstraction, following naming conventions, ...
are hardly new...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,770
Messages
2,569,584
Members
45,076
Latest member
OrderKetoBeez

Latest Threads

Top