89

C++ references have two properties:

  • They always point to the same object.
  • They can not be 0.

Pointers are the opposite:

  • They can point to different objects.
  • They can be 0.

Why is there no "non-nullable, reseatable reference or pointer" in C++? I can't think of a good reason why references shouldn't be reseatable.

Edit: The question comes up often because I usually use references when I want to make sure that an "association" (I'm avoiding the words "reference" or "pointer" here) is never invalid.

I don't think I ever thought "great that this ref always refers to the same object". If references were reseatable, one could still get the current behavior like this:

int i = 3;
int& const j = i;

This is already legal C++, but meaningless.

I restate my question like this: "What was the rationale behind the 'a reference is the object' design? Why was it considered useful to have references always be the same object, instead of only when declared as const?"

Cheers, Felix

TheFogger
  • 2,399
  • 1
  • 20
  • 22
  • 5
    I know this is a bit late, but it Michael Burr's answer seems to be the most complete. It explains Stroustrup's philosophical design decisions. Everyone else seems to be begging the argument (in a round about way). – jww Dec 16 '15 at 10:57

17 Answers17

121

The reason that C++ does not allow you to rebind references is given in Stroustrup's "Design and Evolution of C++" :

It is not possible to change what a reference refers to after initialization. That is, once a C++ reference is initialized it cannot be made to refer to a different object later; it cannot be re-bound. I had in the past been bitten by Algol68 references where r1=r2 can either assign through r1 to the object referred to or assign a new reference value to r1 (re-binding r1) depending on the type of r2. I wanted to avoid such problems in C++.

Michael Burr
  • 333,147
  • 50
  • 533
  • 760
32

In C++, it is often said that "the reference is the object". In one sense, it is true: though references are handled as pointers when the source code is compiled, the reference is intended to signify an object that is not copied when a function is called. Since references are not directly addressable (for example, references have no address, & returns the address of the object), it would not semantically make sense to reassign them. Moreover, C++ already has pointers, which handles the semantics of re-setting.

Geek
  • 26,489
  • 43
  • 149
  • 227
rlbond
  • 65,341
  • 56
  • 178
  • 228
  • I still don't really get the reason why the (in my opinion) useful non-null reseatable reference is not in c++. The problems brought up don't seem difficult to solve, and I think program reliability would increase. Accepting this answer because of the votes. – TheFogger Apr 08 '09 at 23:53
  • 1
    Correction: "though references are _often_ handled as pointers" – Lightness Races in Orbit Oct 04 '11 at 09:41
  • 14
    "The reference *is* the object" is WRONG. Except for the special case of lifetime extension of a temporary, the lifetime of a reference is distinct from the lifetime of the object is refers to. If the reference actually was the object, then the object would be destroyed when the reference went out of scope (or conversely, would live as long as any reference to it), and this is not the case. – Ben Voigt Oct 09 '11 at 03:49
20

Because then you'd have no reseatable type which can not be 0. Unless, you included 3 types of references/pointers. Which would just complicate the language for very little gain (And then why not add the 4th type too? Non-reseatable reference which can be 0?)

A better question may be, why would you want references to be reseatable? If they were, that would make them less useful in a lot of situations. It would make it harder for the compiler to do alias analysis.

It seems that the main reason references in Java or C# are reseatable is because they do the work of pointers. They point to objects. They are not aliases for an object.

What should the effect of the following be?

int i = 42;
int& j = i;
j = 43;

In C++ today, with non-reseatable references, it is simple. j is an alias for i, and i ends up with the value 43.

If references had been reseatable, then the third line would bind the reference j to a different value. It would no longer alias i, but instead the integer literal 43 (which isn't valid, of course). Or perhaps a simpler (or at least syntactically valid) example:

int i = 42;
int k = 43;
int& j = i;
j = k;

With reseatable references. j would point to k after evaluating this code. With C++'s non-reseatable references, j still points to i, and i is assigned the value 43.

Making references reseatable changes the semantics of the language. The reference can no longer be an alias for another variable. Instead it becomes a separate type of value, with its own assignment operator. And then one of the most common usages of references would be impossible. And nothing would be gained in exchange. The newly gained functionality for references already existed in the form of pointers. So now we'd have two ways to do the same thing, and no way to do what references in the current C++ language do.

jalf
  • 243,077
  • 51
  • 345
  • 550
  • 1
    +1. The key part there is "the newly gained functionality for references already existed in the form of pointers." – j_random_hacker Apr 08 '09 at 02:57
  • 7
    There *are* already 3 types. The possibly-null, not-reseatable type is `int* const`. For consistency, there should be 4, as possibly-null and reseatable are quite orthogonal. – MSalters Apr 08 '09 at 12:50
  • 2
    Yes, they're orthogonal, but the language doesn't have to provide every combination. The question is, would the added expressiveness outweigh the added complexity? C++ is more than complex enough as it is, so they need a better reason to add a feature than "it doesn't exist yet". – jalf Apr 08 '09 at 13:09
  • 2
    +1 for "So now we'd have two ways to do the same thing, and no way to do what references in the current C++ language do." – Earth Engine May 30 '13 at 00:19
  • There is no reason why j=k would have to to reseat j. You could stick with the current semantics that references have now and add another operation/syntax for reseating, say &j = &k. – pavon Feb 02 '16 at 15:59
6

Intrestingly, many answers here are a bit fuzzy or even beside the point (e.g. it's not because references cannot be zero or similar, in fact, you can easily construct an example where a reference is zero).

The real reason why re-setting a reference is not possible is rather simple.

  • Pointers enable you to do two things: To change the value behind the pointer (either through the -> or the * operator), and to change the pointer itself (direct assign =). Example:

    int a;
    int * p = &a;
    1. Changing the value requires dereferencing: *p = 42;
    2. Changing the pointer: p = 0;
  • References allow you to only change the value. Why? Since there is no other syntax to express the re-set. Example:

    int a = 10;
    int b = 20;
    int & r = a;
    r = b; // re-set r to b, or set a to 20?

In other words, it would be ambiguous if you were allowed to re-set a reference. It makes even more sense when passing by reference:

void foo(int & r)
{
    int b = 20;
    r = b; // re-set r to a? or set a to 20?
}
void main()
{
    int a = 10;
    foo(a);
}

Hope that helps :-)

dhaumann
  • 1,590
  • 13
  • 25
  • Very very true - on a couple points. A reference can be null. int& r = *(int*)NULL And more importantly I think you nailed the real reason, the assignment operator would have two meanings. That seems to line up with Stroustrup's original comment about Algol68 inferring which of the two applies in a given situation & causing confusion. – Gabe Halsmer Aug 17 '23 at 22:23
5

A reference is not a pointer, it may be implemented as a pointer in the background, but its core concept is not equivalent to a pointer. A reference should be looked at like it *is* the object it is referring to. Therefore you cannot change it, and it cannot be NULL.

A pointer is simply a variable that holds a memory address. The pointer itself has a memory address of its own, and inside that memory address it holds another memory address that it is said to point to. A reference is not the same, it does not have an address of its own, and hence it cannot be changed to "hold" another address.

I think the parashift C++ FAQ on references says it best:

Important note: Even though a reference is often implemented using an address in the underlying assembly language, please do not think of a reference as a funny looking pointer to an object. A reference is the object. It is not a pointer to the object, nor a copy of the object. It is the object.

and again in FAQ 8.5 :

Unlike a pointer, once a reference is bound to an object, it can not be "reseated" to another object. The reference itself isn't an object (it has no identity; taking the address of a reference gives you the address of the referent; remember: the reference is its referent).

Brian R. Bondy
  • 339,232
  • 124
  • 596
  • 636
5

A reseatable reference would be functionally identical to a pointer.

Concerning nullability: you cannot guarantee that such a "reseatable reference" is non-NULL at compile time, so any such test would have to take place at runtime. You could achieve this yourself by writing a smart pointer-style class template that throws an exception when initialised or assigned NULL:

struct null_pointer_exception { ... };

template<typename T>
struct non_null_pointer {
    // No default ctor as it could only sensibly produce a NULL pointer
    non_null_pointer(T* p) : _p(p) { die_if_null(); }
    non_null_pointer(non_null_pointer const& nnp) : _p(nnp._p) {}
    non_null_pointer& operator=(T* p) { _p = p; die_if_null(); }
    non_null_pointer& operator=(non_null_pointer const& nnp) { _p = nnp._p; }

    T& operator*() { return *_p; }
    T const& operator*() const { return *_p; }
    T* operator->() { return _p; }

    // Allow implicit conversion to T* for convenience
    operator T*() const { return _p; }

    // You also need to implement operators for +, -, +=, -=, ++, --

private:
    T* _p;
    void die_if_null() const {
        if (!_p) { throw null_pointer_exception(); }
    }
};

This might be useful on occasion -- a function taking a non_null_pointer<int> parameter certainly communicates more information to the caller than does a function taking int*.

j_random_hacker
  • 50,331
  • 10
  • 105
  • 169
  • 6
    WRONG. You can trivially guarantee that a reseatable reference is not null. When reseating, you would also take an lvalue, just like with initialization. E.g. int foo[0] = {0}; int ref = foo[0]; ref =&= foo[1] /* Reseats ref, doesn't assign to foo[0] */ – MSalters Apr 08 '09 at 12:55
  • 1
    @MSalters: No, requiring lvalues doesn't guarantee the reseatable reference is non-null any more than initialising a regular reference does -- see 8.3.2.4. E.g.: "int &r = *static_cast(0);". There's a world of difference between "x is forbidden" and "x produces undefined behaviour." – j_random_hacker Apr 09 '09 at 05:35
  • 1
    @MSalters: As a side issue, you could have phrased your comment in a less hostile manner without sacrificing any information content. But you chose not to -- why? – j_random_hacker Apr 09 '09 at 05:48
  • 1
    8.3.2.4 in fact states exactly what I said: "A null reference cannot exist in a well-defined (C++) program". The C++ standard basically covers two subjects: what is a well-defined C++ program, and how do they behave. "Nasal demons" were invented to make explicit the limits of the standard. – MSalters Apr 09 '09 at 07:45
  • 1
    And comments are only 300 characters. You'll see that I already abbreviated "reference" to "ref" to make it fit. "Wrong" has many synonyms, many more friendly, but few of those take 5 letters. – MSalters Apr 09 '09 at 07:48
  • 1
    A statement of the form "A **well-defined** program cannot do x with y" is no more a guarantee that x cannot happen than writing "// Don't do x" in y's header file is, and just as unhelpful. And that is the only "guarantee" your reseatable, non-nullable reference provides -- an empty semantic one. – j_random_hacker Apr 09 '09 at 09:16
  • 3
    Also, you could have safely abbreviated "WRONG." all the way down to 0 characters. – j_random_hacker Apr 09 '09 at 09:18
4

It would probably have been less confusing to name C++ references "aliases"? As others have mentioned, references in C++ should be though of as the variable they refer to, not as a pointer/reference to the variable. As such, I can't think of a good reason they should be resettable.

when dealing with pointers, it often makes sense allowing null as a value (and otherwise, you probably want a reference instead). If you specifically want to disallow holding null, you could always code your own smart pointer type ;)

snemarch
  • 4,958
  • 26
  • 38
  • +1 for the smart pointer idea; I would have said the same thing. New features aren't considered for the language if it's already possible to accomplish with the existing standard. – Mark Ransom Apr 08 '09 at 03:13
2

C++ references can sometimes be forced to be 0 with some compilers (it's just a bad idea to do so*, and it violates the standard*).

int &x = *((int*)0); // Illegal but some compilers accept it

EDIT: according to various people who know the standard much better than myself, the above code produces "undefined behavior". In at least some versions of GCC and Visual Studio, I've seen this do the expected thing: the equivalent of setting a pointer to NULL (and causes a NULL pointer exception when accessed).

Mr Fooz
  • 109,094
  • 6
  • 73
  • 101
  • "it's just a bad idea": because the utility of such a critter is, um, limited. – dmckee --- ex-moderator kitten Apr 08 '09 at 02:09
  • It can occur accidentally though, so it's good to know of the possibility. I've harped on this subject before. – Mark Ransom Apr 08 '09 at 03:10
  • This code is illegal: in valid C++ code, this must never happen. So no, references CANNOT ever be 0, as guaranteed by the C++ standard. – Konrad Rudolph Apr 08 '09 at 09:30
  • C++ references cannot be "0". it's like saying "non-static functions are the same as static functions, because they don't need a object to be called". – Johannes Schaub - litb Apr 08 '09 at 10:32
  • Actually references can be NULL, just that as soon as they are used in any way there's the equivalent of a NULL pointer exception raised. I have done this way back in the past and it did create a whole mess of problems. However the fact remains that you can actually set a reference to 0. – Dominik Grabiec Apr 08 '09 at 11:10
  • Nope - the Undefined Behavior already happened at *((int*)0). What happens after that no longer is C++. So don't use C++ terms like reference, NULL or exception for anything that happens afterwards. – MSalters Apr 08 '09 at 12:59
  • 2
    The "undefined behavior" excuse is fine in discussions like this, but doesn't help when you're trying to track down a bug. While undefined, the behavior is usually quite predictable. And insidious, because the crash is often far removed from the cause. – Mark Ransom Apr 08 '09 at 19:25
  • Just to be clear, I agree that the expression *((int*)0) is a bug. But it's going to compile just fine, and your program probably won't crash at that particular spot. See http://stackoverflow.com/questions/57483/difference-between-pointer-variable-and-reference-variable-in-c/57656#57656 – Mark Ransom Apr 08 '09 at 19:32
  • I and i think others don't say that it will necessarily crash your app. We just say that it's wrong to say that it's "possible to have a reference that is NULL". Just because compilers do allow it in realms of undefined behavior doesn't mean it's allowed by the language. – Johannes Schaub - litb Apr 08 '09 at 19:43
  • it's true that originally, the indent was to say that it's valid to dereference the null pointer unless an rvalue was tried to read ( http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232 ), but in fact all the concept of an lvalue is based on entities. There is no such "empty lvalue". – Johannes Schaub - litb Apr 08 '09 at 19:47
  • saying that it's possible to have a null reference will confuse people that don't know better, making them believe that the language actually allows that. and i argue that it's actually very helpful to know about it when trying to track down a bug. People that actually count on what C++ guarantees.. – Johannes Schaub - litb Apr 08 '09 at 19:48
  • .. may read stuff of a reference and then crash because the reference wasn't actually set to anything. I only say what famous herb sutter already said "know what you write and write what you know". make a big fat warning on any answer like that saying "this is invalid - but an interesting insight!". – Johannes Schaub - litb Apr 08 '09 at 19:50
  • Core issue 232 is still drafting; it's not in C++2003. In its current state, it would introduce "references to empty lvalues", and those are functionally equivalent to null references. – MSalters Apr 09 '09 at 07:56
1

This is not actually an answer, but a workaround for this limitation.

Basically, when you try to "rebind" a reference you are actually trying to use the same name to refer to a new value in the following context. In C++, this can be achieve by introducing a block scope.

In jalf's example

int i = 42;
int k = 43;
int& j = i;
//change i, or change j?
j = k;

if you want to change i, write it as above. However, if you want to change the meaning of j to mean k, you can do this:

int i = 42;
int k = 43;
int& j = i;
//change i, or change j?
//change j!
{
    int& j = k;
    //do what ever with j's new meaning
}
Earth Engine
  • 10,048
  • 5
  • 48
  • 78
1

You can't do this:

int theInt = 0;
int& refToTheInt = theInt;

int otherInt = 42;
refToTheInt = otherInt;

...for the same reason why secondInt and firstInt don't have the same value here:

int firstInt = 1;
int secondInt = 2;
secondInt = firstInt;
firstInt = 3;

assert( firstInt != secondInt );
John Dibling
  • 99,718
  • 31
  • 186
  • 324
0

I agree with the accepted answer. But for constness, they behave much like pointers though.

struct A{
    int y;
    int& x;
     A():y(0),x(y){}
};

int main(){
  A a;
  const A& ar=a;
  ar.x++;
}

works. See

Design reasons for the behavior of reference members of classes passed by const reference

Community
  • 1
  • 1
Fabio Dalla Libera
  • 1,297
  • 1
  • 10
  • 24
0

There's a workaround if you want a member variable that's a reference and you want to be able to rebind it. While I find it useful and reliable, note that it uses some (very weak) assumptions on memory layout. It's up to you to decide whether it's within your coding standards.

#include <iostream>

struct Field_a_t
{
    int& a_;
    Field_a_t(int& a)
        : a_(a) {}
    Field_a_t& operator=(int& a)
    {
        // a_.~int(); // do this if you have a non-trivial destructor
        new(this)Field_a_t(a);
    }
};

struct MyType : Field_a_t
{
    char c_;
    MyType(int& a, char c)
        : Field_a_t(a)
        , c_(c) {}
};

int main()
{
    int i = 1;
    int j = 2;
    MyType x(i, 'x');
    std::cout << x.a_;
    x.a_ = 3;
    std::cout << i;
    ((Field_a_t&)x) = j;
    std::cout << x.a_;
    x.a_ = 4;
    std::cout << j;
}

This is not very efficient as you need a separate type for each reassignable reference field and make them base classes; also, there's a weak assumption here that a class having a single reference type won't have a __vfptr or any other type_id-related field that could potentially destroy runtime bindings of MyType. All the compilers I know satisfy that condition (and it would make little sense not doing so).

lorro
  • 10,687
  • 23
  • 36
0

I would imagine that it is related to optimization.

Static optimization is much easier when you can know unambiguously what bit of memory a variable means. Pointers break this condition and re-setable reference would too.

dmckee --- ex-moderator kitten
  • 98,632
  • 24
  • 142
  • 234
0

Because sometimes things should not be re-pointable. (E.g., the reference to a Singleton.)

Because it's great in a function to know that your argument can't be null.

But mostly, because it allows use to have something that really is a pointer, but which acts like a local value object. C++ tries hard, to quote Stroustrup, to make class instances "do as the ints d". Passing an int by vaue is cheap, because an int fitss into a machine register. Classes are often bigger than ints, and passing them by value has significant overhead.

Being able to pass a pointer (which is often the size of an int, or maybe two ints) that "looks like" a value object allows us to write cleaner code, without the "implementation detail" of dereferences. And, along with operator overloading, it allows us to write classes use syntax similar to the syntax used with ints. In particular, it allows us to write template classes with syntax that can be equally applied to primitive, like ints, and classes (like a Complex number class).

And, with operator overloading especially, there are places were we should return an object, but again, it's much cheaper to return a pointer. Oncve again, returning a reference is our "out.

And pointers are hard. Not for you, maybe, and not to anyone that realizes a pointer is just the value of a memory address. But recalling my CS 101 class, they tripped up a number of students.

char* p = s; *p = *s; *p++ = *s++; i = ++*p;

can be confusing.

Heck, after 40 years of C, people still can't even agree if a pointer declaration should be:

char* p;

or

char *p;
tpdi
  • 34,554
  • 11
  • 80
  • 120
  • 1
    @GMan: You have a typo there. You said the correct way is "char *p" where it is obviously "char* p" since the type is pointer-to-char. Just a helpful, erm, pointer. :) – John Dibling Apr 08 '09 at 02:51
  • @John: *Unfortunately*, C and C++ syntax rules break declarations into two parts. To illustrate: "char *p, c;" declares 1 pointer-to-char called p and one character (NOT pointer-to-char) called c. I know, yuck. :/ – j_random_hacker Apr 08 '09 at 02:59
  • `char *p` says that `*p` is a `char`. I came from a Pascal background, where `var p: ^Char` would be the syntax, but I still find it weird when I see Pascal-style `char*` pointer syntax in C/C++... Especially when multiple variables are defined at once e.g. `char* x, y, z` – Mark K Cowan Jul 27 '15 at 16:12
0

I always wondered why they didn't make a reference assignment operator (say :=) for this.

Just to get on someone's nerves I wrote some code to change the target of a reference in a structure.

No, I do not recommend repeating my trick. It will break if ported to a sufficiently different architecture.

Joshua
  • 40,822
  • 8
  • 72
  • 132
0

The fact that references in C++ are not nullable is a side-effect of them being just an alias.

hasen
  • 161,647
  • 65
  • 194
  • 231
-1

Being half serious: IMHO to make them little more different from pointers ;) You know that you can write:

MyClass & c = *new MyClass();

If you could also later write:

c = *new MyClass("other")

would it make sense to have any references alongside with pointers?

MyClass * a =  new MyClass();
MyClass & b = *new MyClass();
a =  new MyClass("other");
b = *new MyClass("another");