18

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.

Community
  • 1
  • 1
cpuer
  • 7,413
  • 14
  • 35
  • 39

9 Answers9

9

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.

Nawaz
  • 353,942
  • 115
  • 666
  • 851
  • Seems like that would call `operator=(A*, A**)`. Which I think would be as rare as `operator=(A&, A*&)` is today. – Ben Voigt May 30 '11 at 02:18
  • @Ben: I didn't understand what you're trying to say. – Nawaz May 30 '11 at 02:21
  • @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`;. – Ben Voigt May 30 '11 at 02:25
  • 1
    @Nawaz,I can understand your answer completely.@Ben Voigt,though I think your answer is also right,but haven't understood it yet... – cpuer May 30 '11 at 02:33
  • @cpuer: I added one more paragraph at the end. – Nawaz May 30 '11 at 02:40
  • 1
    @Nawaz ,aha,so my conclusion is right: reference is just a more **beautiful** way to use pointers:) – cpuer May 30 '11 at 02:43
  • @cpuer: Exactly, my friend. References are permanently dereferenced pointers. – Nawaz May 30 '11 at 02:47
5

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.

?

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • @Ben Voigt,I think it would match both. – cpuer May 30 '11 at 02:04
  • 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;` – Daniel May 30 '11 at 02:07
  • @cpuer: Then how would the operator know whether to print one character, or up to the first NUL element? – Ben Voigt May 30 '11 at 02:07
  • @Dani: Then how do you do pointer arithmetic? Does `complex a[4]; cout << a + 1;` print the sum of the first element and one, or the second element? – Ben Voigt May 30 '11 at 02:08
  • @Ben Voigt,in other words,it's because the ambiguity of c pointer syntax that cause references to be introduced? – cpuer May 30 '11 at 02:14
  • @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 May 30 '11 at 02:15
  • @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 May 30 '11 at 02:16
1

Consider the statement

c= a+b

where the + operator has been overloaded. This statement can be interpreted by the compiler as

c=operator+ (a, b)

Since, here addresses of variables are not getting passed, so we cannot collect them in pointer variables.

If we want to collect them in pointer variables , then we have to modify the statement as follows:

c=&a+&b;

But this means that we are trying to add addresses of a and b and not their values. At such times only references can be used to save memory.

Rahul Gandhi
  • 1,035
  • 1
  • 11
  • 24
1

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.

Christian Rau
  • 45,360
  • 10
  • 108
  • 185
  • @Christian Rau,`&a + &b` is ugly but not complicated than reference. – cpuer May 30 '11 at 01:57
  • @cpuer: Yes, but `a+b` is a lot more intuitive than `&a+&b1`. – In silico May 30 '11 at 01:57
  • 1
    @In silico ,So reference is just a more **beautiful** way to use pointers? – cpuer May 30 '11 at 02:00
  • @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. – In silico May 30 '11 at 02:23
  • @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. – Ben Voigt May 30 '11 at 02:43
  • @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. – In silico May 30 '11 at 08:32
  • @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](http://www.parashift.com/c++-faq-lite/references.html#faq-8.1). 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. – Ben Voigt May 30 '11 at 13:56
  • @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). – In silico May 30 '11 at 20:58
  • @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. – Ben Voigt May 30 '11 at 21:22
  • @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. – In silico May 30 '11 at 22:02
1

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

Benjamin Lindley
  • 101,917
  • 9
  • 204
  • 274
  • Well, the compiler could pass the address of each operand. – Ben Voigt May 30 '11 at 02:05
  • @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? – Benjamin Lindley May 30 '11 at 02:08
  • 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. – Ben Voigt May 30 '11 at 02:12
  • @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. – Benjamin Lindley May 30 '11 at 02:35
  • 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. – Ben Voigt May 30 '11 at 02:46
1

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

Mahesh
  • 34,573
  • 20
  • 89
  • 115
  • 1
    Circular reasoning, and not entirely true. Even under the current rules, only one operand needs to be a user-defined type. – Ben Voigt May 30 '11 at 02:11
  • 1
    Also, by the language standard, a pointer *is* an object, in contrast to a reference, which isn't. :) – Xeo May 30 '11 at 02:18
0

It's 2019 and you still do not have access to the classes of native types. There is no way to override operators on them.

Pointers are (like char, int, float, etc...) a native type. You can create an object that behaves like a pointer and overload operators [->, *], but that will not overload [->, *] on the the native pointer. You may also, for example, create an object that behaves like an int and overload [+, -, *, /], but that will not overload [+, -, *, /] on the native int.

For pragmatic rational, imagine the chaos if

this->member

had user-defined meaning.

References are an unrelated topic, IMHO.

Samuel Danielson
  • 5,231
  • 3
  • 35
  • 37
0

Operators can't be overloaded when both types involved are built-in types (like int, float or any kind of pointer). You can overload operator for one class and one primitive type (or you can just use type conversion). For example you can add std::string and const char *.

John
  • 2,295
  • 1
  • 20
  • 25
  • 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 May 30 '11 at 02:09
  • 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. – John May 30 '11 at 02:34
0

Which implies that operator overloading cannot work with pointer.

It doesn't imply that at all. It states that providing references is an essential notational convenience so that the programmer doesn't have to liberally use the address-of operator.

It is also the case that operator overloading doesn't work with pointers, but that's basically because there is no syntax for it. Why? Ask Stroustrup.

Your IMO is correct provided a dereference operator is used before the pointer.

user207421
  • 305,947
  • 44
  • 307
  • 483