Why isn't operator overloading for pointers allowed to work?

Question

As per the comment under this answer, references were introduced primarily to support operator overloading which quotes Bjarne Stroustrup:

References were introduced primarily to support operator overloading. C passes every function argument by value, and where passing an object by value would be inefficient or inappropriate the user can pass a pointer. This strategy doesn’t work where operator overloading is used. In that case, notational convenience is essential so that a user cannot be expected to insert address− of operators if the objects are large.

Which implies that operator overloading can't work with pointer. But it doesn't clearly explain why operator overloading with pointers can't work. Why wouldn't operator overloading work for pointers?

IMO where references are used, pointers can also be used in its place.

Solution 1

Because if it was allowed, then it would not look good, and wouldn't be as intuitive as its with reference.

Suppose it is allowed, then you would write:

struct A{};
A a, *pa, b;

a = pa ;//doesn't look good, also not intuitive. (not real C++)

It doesn't look good, because on left side you've non-pointer, on right side you've pointer. Looks very very weird. Also, since the types don't match, it doesn't look very intuitive as to what exactly its doing. I mean, you're assigning pointer to a non-pointer; what such an assignment is supposed to do? Copying the content of the address pointed to by pointer to the destination (non-pointer) is not very inttuitive.

On the other hand, as its allowed with reference (the reality, not a supposition):

a = b; //looks good, intuitive, as now both side is same type

With reference, you've both side same type, its only when b gets passed to operator=() as argument, it is passed by reference (or say by pointer, as references are syntactic sugar of pointers.) to avoid unnecessary copy, which in turn doesn't hinder performance, as it would if it is passed by value.

It would be also interesting to note that not only b is passed by reference (or pointer underneath), a also gets passed to the function by pointer, because we know in the function, the keyword this is actually a pointer.

So references were introduced in C++, to make whole thing look good and intuitive for programmers, otherwise they're pointers underneath. In fact, most compilers implement references using pointers (pointer-mechanism) internally.

Solution 2

Why doesn't it work for pointers? Because it's ambiguous. Would

ostream* operator<<(ostream* s, const char* c);

match

cout << 'a';

or

cout << "a";

?

Also, you can't use address-of (&) with a temporary. What should this do:

complex<double> a, b, c;
cout << a + b * c;

since b * c is a temporary, and the sum is also.

?

Solution 3

Operator overloading work on objects but pointer is not an object by itself. It points to an object.

Solution 4

With the plus operator overloaded for a heavy class, you would have to write either a + b (by-value, inefficient) or &a + &b (ugly and complicated) to add two objects of this class. But with references you get by-ref even when writing a + b.

Solution 5

Because most operators already have an alternate established meaning when applied to pointers.

View more solutions

Comments

[cpuer]

@Christian Rau,&a + &b is ugly but not complicated than reference.

[In silico]

@cpuer: Yes, but a+b is a lot more intuitive than &a+&b1.

[cpuer]

@In silico ,So reference is just a more beautiful way to use pointers?

[cpuer]

@Ben Voigt,I think it would match both.

[Ben Voigt]

Well, the compiler could pass the address of each operand.

[Daniel]

It shouldn't automatically take pointer, it won't match cout << 'a'; but it will match cout << &'a'; unless the compiler throws lvalue problem. in that case you can use char a = 'a'; cout << &a;

[Ben Voigt]

@cpuer: Then how would the operator know whether to print one character, or up to the first NUL element?

[Benjamin Lindley]

@Ben Voigt: Then how would it be able to differentiate between two functions, one of which takes a pointer, and the other takes a value?

[Ben Voigt]

@Dani: Then how do you do pointer arithmetic? Does complex<double> a[4]; cout << a + 1; print the sum of the first element and one, or the second element?

[Ben Voigt]

Circular reasoning. You can't cite the current set of rules as justification for the current set of rules. You need a rationale.

[Ben Voigt]

Circular reasoning, and not entirely true. Even under the current rules, only one operand needs to be a user-defined type.

[Ben Voigt]

A problem I already highlighted in my answer. It would be feasible if the compiler always took the address of each operand, such that when an operand was a pointer, the implementation received a double pointer. But it would be confusing for sure.

[cpuer]

@Ben Voigt,in other words,it's because the ambiguity of c pointer syntax that cause references to be introduced?

[Ben Voigt]

@Dani: No, there could have been a language which, when the programmer wrote a + b, transformed it to operator+(&a, &b) if either a or b was a user-defined type, and builtin+(a, b) otherwise. But you'd still have a problem with addresses of temporaries.

[Ben Voigt]

@cpuer: C pointers aren't ambiguous, but having the compiler take the address for you would be confusing. So the solution (listen carefully) involves having the compiler take the address for you, but it then hides the fact that it's done so. Which definitely is not less confusing.

[Ben Voigt]

Seems like that would call operator=(A*, A**). Which I think would be as rare as operator=(A&, A*&) is today.

[Xeo]

Also, by the language standard, a pointer is an object, in contrast to a reference, which isn't. :)

[Nawaz]

@Ben: I didn't understand what you're trying to say.

[In silico]

@cpuer: Don't think of references as pointers (or some variant thereof), because they can't do pointer arithmetic, you can't "reseat" reference, and taking the address of a reference gets you the address of the object it refers to (instead of the reference itself). It's much more useful to think of references as aliases to the object it refers to (they may be implemented via pointers by the compiler, but that's an implementation detail). Any change that you perform on the alias changes the original object.

[Ben Voigt]

@Nawaz: In a hypothetical C++ developed in an alternate universe, where user-defined operators received pointers to their operand instead of a reference, your line of code a = pa;, which has LHS of type struct A, and RHS of type struct A*, would receive a pointer to each, thus operator=(struct A*, struct A**). Most people would define operator=(struct A*, struct A*), to enable a = b;.

[cpuer]

@Nawaz,I can understand your answer completely.@Ben Voigt,though I think your answer is also right,but haven't understood it yet...

[John]

The reason is very simple. If overloading built-in operators would be possible (like custom int operator+(int, int)) then you would end up with inconsistent behaviour. Your code would use your operator and all other code (libraries) would use other (built-in) operator.

[Benjamin Lindley]

@Ben Voigt: But you're introducing the problem of ambiguity yourself when you say the compiler could pass the address of each operand. The solution to that problem is not to introduce it in the first place and have operands act just like regular function arguments. Then that leaves you with the problem that I point out.

[Nawaz]

@cpuer: I added one more paragraph at the end.

[Ben Voigt]

@In silico: Every time I've heard references described as aliases (or "just another name for the variable"), people managed to confuse issues of lifetime. A reference is best thought of as a pointer with a pointer-dereference (*) permanently stuck on the front.

[cpuer]

@Nawaz ,aha,so my conclusion is right: reference is just a more beautiful way to use pointers:)

[Ben Voigt]

A double pointer is not ambiguous with a single pointer. But most new programmers don't understand double pointers even as well as references (and references not as well as pointers). Although that might have turned out differently in an alternate universe where C++ didn't have references.

[Nawaz]

@cpuer: Exactly, my friend. References are permanently dereferenced pointers.

[In silico]

@Ben Voigt: That's a good point. It's really meant to be more of an analogy than anything else, anyway. I like your description of how references work, but it doesn't explain why const references extend the lifetime of temporaries but non-const references don't, which is obviously not how pointers behave. To be fair, it is an unusual case.

[Ben Voigt]

@In silico: Lifetime extension of temporaries can't be explained by either approach... has to be learned as a special feature of references either way. What I'm wary of is the horrible explanation in the parashift FAQ. If a reference were the object, then the destructor would be called when the reference goes out of scope. But a reference bound to a non-temporary object does not destroy the object. The reference is bound, it is not itself a name for the object.

[In silico]

@Ben Voigt: I agree thinking of references as an object doesn't accurately reflect the lifetime of the object it refers to. It may be the exact way I explain it, but I the people I explained it to doesn't seem to be confused over object lifetimes with the "alias" analogy. When I explain it the example I used is that a person's nickname is an "alias" to the actual person. When you refer to someone by their nickname, you're actually referring to the original person (and of course nicknames do not affect the lifetime of the original person).

[Ben Voigt]

@In silico: But a reference isn't an alias for an object, like a pointer, it's an alias for the memory that object resides in. You can tell the difference, using placement new (carefully not deallocating the memory, which would result in undefined behavior) or a union.

[In silico]

@Ben Voigt: Yes there is a difference, but for all intents and purposes if I'm teaching someone who doesn't know the first thing about C++ references it's IMHO easier to think of the object and the memory it occupies as the same thing (a higher-level of abstraction, if you will). I never said that the "alias" concept was a perfect analogy without caveats.