[dogles]

I disagree with this argument. Modern programming is done with groups of people; you are not only communicating your intent to the machine, you are communicating your intent with fellow engineers. It is in this case that nuance is important. For example, C++ references and pointers are exactly the same as far as the machine cares. But the difference is important for communicating intent to other engineers.

This isn't to say that C++ lacks significant flaws, but I don't think nuance and variety of expression is one of them.

[jeorgun]

Out of curiosity: what intent would you say is communicated by choosing references over pointers, or vice versa? I'm relatively new to C++, but I haven't noticed any real difference beyond personal preference.

[im3w1l]

If a function takes a pointer parameter, then you have to think about if it is pointing to one object or an array.

If it is passed by reference I'd be less inclined (personal opinion) to think the reference is stored somewhere, while a pointer argument might be saved somewhere for some time.

A function invocation with reference looks the same as a function invocation with value, so on a quick glance, someone might think that the parameter will remain unchanged.

It is easy to convert a pass by value to a pass by reference (just put const &, vs changing all dots to arrows with pointers) to speed up a slow copy of a large object, so I may get the impression that that was the reason for using a reference when reading the code.

[stonemetal]

Pointers can be null references can not, therefore if you use a reference then you are communicating nulls not allowed. You can't new or delete with a reference, so you are saying something about the lifetime of the object referenced(That this code absolutely refuses to manage it).

[catnaroek]

This is only partially true. A C++ reference can outlive the object it references. A better argument would be Rust's borrowed pointers, which are statically checked to never point to an invalid object throughout their entire lifetimes.

To talk about lifetimes, you need linear logic in the core language. Merely having destructors is not enough.

[stonemetal]

This is only partially true. A C++ reference can outlive the object it references.

I didn't mean to imply that it couldn't, just that by using a reference instead of a pointer you are disclaiming responsibility for lifetime management of the referenced item since you can not delete a reference.

C++ being what it is, one can ref = *(new object());, delete &ref;, but the intention you are expressing by using a reference is more hands off in nature. It isn't retargetable, no built-in ability to new\delete, etc.

[catnaroek]

Manually making sure a reference does not outlive the referenced object (or, at least, that a reference is not used after the object has been destroyed) looks pretty much like "lifetime management" to me. What C++ affords you is merely ownership management.

[sixthloginorso]

You are also indicating that the reference is not meant to be "reseated", i.e. that you aren't going to swap the object at the end of it for another, like you could do with a pointer.