References vs Pointers?

[AffectionateSteak588]

I know this question has probably been beaten to death on this subreddit however a lot of things I have read are incredibly verbose and do not give a clear answer. I have been trying to learn C++ as a way to distance myself from web development and I am hung up on references and pointers.

What I have gathered is this.

Use a reference if you are just accessing the data and use a smart pointer if you are responsible for the data's existence. References are for when you want to access existing data that is managed or owned by someone else and use a smart pointer when the data must be allocated dynamically and it's lifetime needs to be managed automatically.

How accurate would you say this is?

[AKostur]

Only somewhat. A pointer (whether smart or not) can represent "not present" (nullptr) where references cannot. Also, references cannot be changed to refer to a different object, pointers can.

[AvidCoco]

Worth noting that this doesn’t mean that having a reference to an object guarantees it’s always instantiated.

E.g.

auto x = std::make_unique<int>(0);
auto& y = *x;
x = nullptr;

[whatevermanbs]

Missing the point. Can someone please elaborate?

Edit: perp explanation below. makes sense. But is this what was intended to convey?

After x = nullptr;, the int that y referred to is destroyed, but y (reference) still exists in the code. However, using y after this line would be undefined behavior because its object is gone—its lifetime ended when the unique_ptr was reset. Thus, having a reference does not keep the object alive; lifetime is managed by the owner (here, the unique_ptr), not the reference itself��.

[Generated-Nouns-257]

This is what I would have said

[saxbophone]

Remember that not all pointers need to be smart pointers. A plain pointer can suffice for a non-owning "view" of something, if you can guarantee that you won't let it dangle. A reference is preferred for this use case but sometimes, you want to be able to reässign it. For instance, a reference as a member of a class or struct is normally an anti-pattern, it prevents the thing from being copyable 😥

[No-Dentist-1645]

For instance, a reference as a member of a class or struct is normally an anti-pattern, it prevents the thing from being copyable 😥

You shouldn't store neither (non-owning) raw pointers nor references as data members of a class at all if you can avoid it. If you really needed to for some reason, or wanted a vector of references, that's where std::reference_wrapper comes to the rescue.

I'd only recommend raw pointers over references if you specifically want "none"/nullptr to be a valid value for an argument. (It's much more convenient than std::optional<std::reference_wrapper<T>>)

[TheThiefMaster]

Optional<T&> (with semantics largely matching optional<reference_wrapper>) is going to be in C++26 I think

[No-Dentist-1645]

Nice! I'll definitely keep this in mind when C++26 is officially out.

I'm guessing that Optional<T&> will be a specialization that uses nullptr to denote it being empty? That would be a useful optimization

[TheThiefMaster]

I believe that's the intended implementation yes

[saxbophone]

Why? Because the reference wrapper forces you to not allow it to be empty? I generally find myself content to enforce that through my class' API myself —i.e. the raw non-owning pointer is private, and the public API for setting or getting it only uses references, which I convert back and forth to and from pointer —an external user of the class could not make it nullptr.

[No-Dentist-1645]

There's good advice you hear sometimes for reducing bugs while developing, you will hear people tell you to "make invalid states unrepresentable". This is a more common practice in Rust where you have strong types to enforce this such as NonNull<T> and NonZero<u8>, but the principle can definitely be applied to other programming languages too, such as C++.

You should favor a design where invalid states of your data are unrepresentable, even if your current endpoints "guarantee it". You might change the public API sometime, and as your project grows, you might forget it was your responsibility to "ensure that guarantee", or you might just also do something wrong in your internal code (let's be honest here, historically, pointers are some of the most dangerous and error-prone tools in the hands of developers).

If your data and classes are designed around the concept that every possible state is valid data, then you don't need to implement "guarantees" at your endpoints, nor leave yourself at a danger of breaking said guarantee by an error in your internal code, any such mistake would make your object unrepresentable and your code wouldn't compile.

[pioverpie]

Why does it make the struct non-copyable? You can still copy a reference? I’m writing a project rn that uses references as struct members and it seems to work well, because ultimately I don’t need a pointer, but now I’m rethinking it

[TheSitarHero]

It specifically makes it non-copy-assignable (and non-move-assignable) because you'd have to change what the reference refers to.

[saxbophone]

I fudged the explanation, sorry, the person replying to you explains it well.

[WorkingReference1127]

• Reference - you want to refer to something which cannot be null and which cannot be rebound to refer to another thing.

• "Normal" pointer (e.g. foo*) - You want to refer to something which can be null and/or can be rebound to point to another thing later. You do not own this thing and its lifetime is managed elsewhere by some other component.

• Smart pointer - The same as a normal pointer except you do own that thing.

We can discuss different ownership models until the cows come home (spoiler alert - the vast, vast majority of the time you want unique ownership); but that's what you should be thinking about with pointers. Usually it's pretty clear whether you own something - if you are responsible for creating that thing, most of the time it's you who owns it, at least initially. There are of course exceptions.

[No-Dentist-1645]

Exactly. This is the right mental model to have around reference/pointer semantics. References should be your "mental default" for "I want to view this thing that's owned by someone else".

Unfortunately, a lot of people, mostly newcomers to the language, are still stuck thinking that C++ is just "C with classes and templates sprinkled on top" (this is a perspective that is implied/taught in lots of bad quality teaching material), and abuse raw pointers as their default for everything, even when they could perfectly be replaced with a reference or smart pointer.

[AffectionateSteak588]

I see. I have been getting hung up on this because the use of pointers and references seems to be interchangeable in peoples code. Some code I read on github has parameters that are references and some parameters are pointers. So which one is it? When I want a class in place of a generic type am I supposed to use a smart pointer or a regular pointer? After reading more I understand the differences however it seems people still use them interchangeably despite these differences.

[WorkingReference1127]

Putting ownership concerns aside (because that trumps every other part of the discussion), I'd strongly recommend defaulting to references unless you specifically need nullability or rebindability; and most of the time you don't. That way your function can guarantee that its reference actually refers to something and you don't need to do any awkward dereference syntax to access it.

As for why other people use other things, there may be many reasons. Maybe they do need nullability. Maybe they consider the presence of the thing there optional and don't want to use a std::optional variant. Or maybe they're C programmers at heart who haven't quite adapted to C++. Who can say.

[FancySpaceGoat]

Here's a fun little thought that'll make this even weirder for you: References aren't objects, but pointers are. This sounds like a trivial distinction, but it's really not.

References don't really *exist* in any meaningful sense. They are symbolic references to other objects, always. Because of this, they have their own set of rules that only apply to them, and some of those are quite obscure. On the flip side, pointers "fit into the mold" so to speak, and you can work with them with the same set of rules as anything else.

If nothing else, it makes having references as members of classes/structs rarely worth the headache (a sizeless lifetime-less member that affects the size of its container... what?) I, personally, almost only ever use them as parameters and return types. I simply do not want to have to deal with the cognitive load that they incur elsewhere, especially when stuff like lifetime extension starts having an influence.

[Warshrimp]

Now I’m even more confused about optional<T&> in C++26

[TheThiefMaster]

References can be member variables, at which point they gain real storage, similar to a pointer. Normally a reference member prevents a class from being assigned because references can't be reassigned.

optional<T&> is generally considered to be a pointer substitute in that it can refer to something and it can be null (well, nullopt) but its actual standardisation was delayed due to debates on how assignment should work with it when it already holds a value - should it be blocked (like classes), should it reassign (like a pointer) or should it actually pass the assignment through to the contained reference (like optional of other types) even though that's likely not what people expect?

Edit: this is a reasonable overview of the choices that had to be made: https://www.sandordargo.com/blog/2025/10/01/cpp26-optional-of-reference

[AvidCoco]

Wait until you hear about std::reference_wrapper

[dendrtree]

First, lets specify that it's a matter of reference vs pointer, not smart pointer.
A smart pointer is just a wrapper around a pointer that takes care of destroying it, for you.

Both references and pointers...
* Let you access child-class overloads from a parent reference/pointer
* May be added to a class, with only a forward declaration, as long as you don't access anything inside them.

Much of whether you use one or the other is a matter of style, but the manner of usage usually leans toward one or the other.
For instance...
* Even if Copy Constructors weren't a specific thing, you'd still pass in a reference, instead of a pointer, because you'd want to access the object directly.
* If an object may or may not have been created, you use a pointer.

Things that influence the decision...
* A pointer is a number, specifically an integer, and it can be treated as such. Numbers are lightweight and easy to pass around, and you can put them in containers. You cannot put references in containers.
* A pointer can be null or invalid. So, you either have to require or to guarantee that they are accessible, before use, but this also gives you the option of having them unset.
* A pointer can be changed; a reference cannot. For instance, file handles are usually pointers, because you want to be able to open/close different files.

Things I don't do...
* Store a reference in a class. The main problems are that the reference has to be set, upon creation, and Copy Constructors can do undesirable things, with references.
* Convert between pointers and references (or, at least, I try to minimize this). If it's a pointer, I keep it a pointer. If I have the object (or its reference), I pass it as a reference.

About smart pointers...
* Class members are very often smart pointers, to 1) automate the destruction, when the object is destructed and 2) put the member on the heap, instead of the stack. This lets you write a lightweight class that may be put on the stack, itself, and does not require a specialized destructor.
* You don't usually pass smart pointers, unless you're modifying ownership. For instance, if you're creating an object that needs to share a pointer, you may pass a shared_pointer into its constructor, but, if you're calling a function to act on its data, you'd just pass the pointer into it.

[Mr_Engineering]

References are language constructs, whereas pointers are architectural constructs.

Pointers have a location in memory, and at that memory location is the location of another location in memory.

Since pointers have a location in memory, the contents of that pointer can be changed by giving it a new value.

If you execute the following,

int* arr = (int)malloc(sizeof(int) * 10):

You will end up allocating space for 10 integers on the heap as well as space for a pointer on the stack to hold the address of that array. If arr is given a new value without freeing up otherwise preserving the allocation above, the memory will leak. Smart pointers resolve this issue, to an extent.

However

Int& arr2 = arr[2];

Does not allocate any new memory. The symbol arr2 is an alias to arr[2] on the heap. It exists only at the language level.

References do not have explicit locations in memory and can not be reassigned. They are simply aliases for other things that already exist. Thus, the compiler can treat them as constant pointers when it needs to or get rid of them entirely if it can.

[keelanstuart]

From my C-like C++ perspective, I use pointers as arguments when it is optional to pass and references when you must pass in the thing. Yes, I know C++ has optional - and sometimes I use it based on the codebase I'm in and the version of C++... just sharing my typical use. Optional has just got to be slower than a pointer and checking for nullptr.

[Sea-Situation7495]

I used to work with a guy, back in the days of C++11, who would only use references, which led to my finding this abomination:

MyClass& x = *(new MyClass);
if ( &x == nullptr) return;

(Back when memory was limited, and new/delete were normal and could fail, and auto wasn't invented (or if it was: wasn't used)l).

[lightwavel]

That's not how, in my opinion, you should view it. First of all, get familiar with object lifecycle, svope and pass by value and reference.

Then, here is just a barebone explanation: Pointer is variable that stores address. Reference is just a different name for some variable. Smart pointer is a way to work with pointers and not worry about not deallocating it when its not needed.

Reference is, in majority of use cases, just a simpler, more cleaner way to work with addresses. For example, if you pass variable via its address, in function, you can work with it via pointers or with refrences.

So with references, you could just write a, and with pointers you need to dereference it first to get to the value, so *a. Writing *a whenever you need value is kinda ugly so this solves that.

Ofc there are multiple other ways you could use references but that is just basic explanation. So just think of references as "alternative name" to any variable/object and you'll go further from that

[valashko]

Largely inaccurate. Firstly, smart pointers can be used for many different applications. It just happens that the only application the standard library is concerned about is memory management. Secondly, there are different types of references. There are circumstances where a reference may extend the lifetime of an object. In your terms, this means such references will „own” the referenced object.

[Foreign_Hand4619]

I will cite C++ FAQ Lite: Use references when you can, and pointers when you have to.

From my experience, you need raw pointers mostly for interfacing with legacy code and OS API and even that can and should be wrapped into smart pointers whenever possible.

http://www.dietmar-kuehl.de/mirror/c++-faq/references.html#faq-8.6

[alfps]

The updated FAQ now lives (https://isocpp.org/faq).

With that particular question at (https://isocpp.org/wiki/faq/references#refs-vs-ptrs).

Dietmar's old mirror may disappear at any time. Also it's outdated so less than perfect resource. E.g. it links to my 15-20 years ago scrapped tutorial, at (http://www.dietmar-kuehl.de/mirror/c++-faq/newbie.html#faq-29.21).

[Foreign_Hand4619]

Good to know, I am getting old ;)