What is the rationale for difference between -> and . in c/c++? [duplicate]

This question already has answers here: Closed 12 years ago.

Possible Duplicates:

C++: ptr->hello(); /* VERSUS */ (*ptr).hello();

Why does C have a distinction between -> and . ?

I know the difference between the member operator (.) and the member by pointer operator (->).

Why did the C designers create a different operator for this access? Why can't the compiler figure it out on its own?

If you always used a . doe开发者_Python百科s any case exist where it is ambiguous whether you mean a member or a member by pointer?

edit: I'm not looking for the "(*a).b" syntax. I asking why didn't the designers allow you to use "a.b" instead of "a->b"?

---

Would you really want the compiler to "figure it out on its own?" If it did, then the following would evaluate to the same thing (assuming p is a pointer to a struct with a member x):

(*p).x;
p.x

If the dereferencing of the pointer is implicit there, should it be implicit everywhere? Consider:

int* p;
int i = p; // should dereferencing be implicit here as well?

I think that would be far more confusing than having two separate operators.

It can also be helpful to have two operators to help keep track of how many layers of indirection you have. Granted, the -> operator is not strictly necessary for this, since p->x is equivalent to (*p).x, but it does make code a bit clearer and easier to read.

---

Yes the ambiguity comes from being able to override both operators. Best example maybe are shared pointers. A shared pointer can be used with . and -> operators and both have different meanings.

With -> you access the object that is pointed to and with . you access the members of the shared pointer itself.

For instance:

class MyObject {
 public:
    void myFunction() {}
 };
 boost::shared_ptr<MyObject> ptr;
 ptr.use_count(); // calls use_count, which is a member of boost::shared_ptr.
 ptr->myFunction(); // calls MyObject::myFunction, as the operator-> is overriden

---

When you have a language that is, at its core, intended to be a "portable assembler" you don't try to hide implementation details from the user. Of course the compiler can figure out that in the expression a.b the a in question is a pointer. Can you? Reliably? All the time? In hairy, complicated code? And can you not envision a circumstance where not being able to quickly note that a is a pointer could be a problem?

Stop thinking in terms of "hard to write" and start thinking in terms of "easy to read". (Yeah, I know. This goes against the whole C programmer mythos!) You'll be reading code a couple of orders of magnitude more often than you'll be writing it.

---

C++ lets you overide the -> operator. When you have a smart pointer class like std::auto_ptr, the same variable might support both . and ->, on which you use . to access members of the auto_ptr, and -> to access members of the pointer which it contains.

---

(*a).b is the same as a->b

---

Both fo->bar and (*fo).bar do the same thing!

The language simply provides an operator for indirect access, namely the arrow (->) and treats it as a single symbol.

---

The -> operator is just an easier way to reference an object's method or member by its pointer, instead of using something like (*p).member or (*p).method.

Example:

MyClass *MyObj;

MyObj->method(); is better to read and understand than (*MyObj).method();