What real use does a double pointer have? [closed]

Answer 1

Honestly, in well-written C++ you should very rarely see a T** outside of library code. In fact, the more stars you have, the closer you are to winning an award of a certain nature.

That's not to say that a pointer-to-pointer is never called for; you may need to construct a pointer to a pointer for the same reason that you ever need to construct a pointer to any other type of object.

In particular, I might expect to see such a thing inside a data structure or algorithm implementation, when you're shuffling around dynamically allocated nodes, perhaps?

Generally, though, outside of this context, if you need to pass around a reference to a pointer, you'd do just that (i.e. T*&) rather than doubling up on pointers, and even that ought to be fairly rare.

On Stack Overflow you're going to see people doing ghastly things with pointers to arrays of dynamically allocated pointers to data, trying to implement the least efficient "2D vector" they can think of. Please don't be inspired by them.

In summary, your intuition is not without merit.

Answer 2

I am very very new to c++ and can't get my head around the use of double, triple pointers etc.. What is the point of them?

The trick to understanding pointers in C is simply to go back to the basics, which you were probably never taught. They are:

• Variables store values of a particular type.
• Pointers are a kind of value.
• If x is a variable of type T then &x is a value of type T*.
• If x evaluates to a value of type T* then *x is a variable of type T. More specifically...
• ... if x evaluates to a value of type T* that is equal to &a for some variable a of type T, then *x is an alias for a.

Now everything follows:

int x = 123;

x is a variable of type int. Its value is 123.

int* y = &x;

y is a variable of type int*. x is a variable of type int. So &x is a value of type int*. Therefore we can store &x in y.

*y = 456;

y evaluates to the contents of variable y. That's a value of type int*. Applying * to a value of type int* gives a variable of type int. Therefore we can assign 456 to it. What is *y? It is an alias for x. Therefore we have just assigned 456 to x.

int** z = &y;

What is z? It's a variable of type int**. What is &y? Since y is a variable of type int*, &y must be a value of type int**. Therefore we can assign it to z.

**z = 789;

What is **z? Work from the inside out. z evaluates to an int**. Therefore *z is a variable of type int*. It is an alias for y. Therefore this is the same as *y, and we already know what that is; it's an alias for x.

No really, what's the point?

Here, I have a piece of paper. It says 1600 Pennsylvania Avenue Washington DC. Is that a house? No, it's a piece of paper with the address of a house written on it. But we can use that piece of paper to find the house.

Here, I have ten million pieces of paper, all numbered. Paper number 123456 says 1600 Pennsylvania Avenue. Is 123456 a house? No. Is it a piece of paper? No. But it is still enough information for me to find the house.

That's the point: often we need to refer to entities through multiple levels of indirection for convenience.

That said, double pointers are confusing and a sign that your algorithm is insufficiently abstract. Try to avoid them by using good design techniques.

Answer 3

Multiple indirection is largely a holdover from C (which has neither reference nor container types). You shouldn't see multiple indirection that much in well-written C++, unless you're dealing with a legacy C library or something like that.

Having said that, multiple indirection falls out of some fairly common use cases.

In both C and C++, array expressions will "decay" from type "N-element array of T" to "pointer to T" under most circumstances¹. So, assume an array definition like

T *a[N]; // for any type T

When you pass a to a function, like so:

foo( a );

the expression a will be converted from "N-element array of T *" to "pointer to T *", or T **, so what the function actually receives is

void foo( T **a ) { ... }

A second place they pop up is when you want a function to modify a parameter of pointer type, something like

void foo( T **ptr )
{
  *ptr = new_value();
}

void bar( void )
{
  T *val;
  foo( &val );
}

Since C++ introduced references, you probably won't see that as often. You'll usually only see that when working with a C-based API.

You can also use multiple indirection to set up "jagged" arrays, but you can achieve the same thing with C++ containers for much less pain. But if you're feeling masochistic:

T **arr;

try
{
  arr = new T *[rows];
  for ( size_t i = 0; i < rows; i++ )
    arr[i] = new T [size_for_row(i)];
}
catch ( std::bad_alloc& e )
{
  ...
}

But most of the time in C++, the only time you should see multiple indirection is when an array of pointers "decays" to a pointer expression itself.

---

1. The exceptions to this rule occur when the expression is the operand of the sizeof or unary & operator, or is a string literal used to initialize another array in a declaration.

Answer 4

An important reason why you should/must know about pointer-to-pointer-... is that you sometimes have to interface with other languages (like C for instance) through some API (for instance the Windows API).

Those APIs often have functions that have an output-parameter that returns a pointer. However those other languages often don't have references or compatible (with C++) references. That's a situation when pointer-to-pointer is needed.

Answer 5

In many situations, a Foo*& is a replacement for a Foo**. In both cases, you have a pointer whose address can be modified.

Suppose you have an abstract non-value type and you need to return it, but the return value is taken up by the error code:

error_code get_foo( Foo** ppfoo )

or

error_code get_foo( Foo*& pfoo_out )

Now a function argument being mutable is rarely useful, so the ability to change where the outermost pointer ppFoo points at is rarely useful. However, a pointer is nullable -- so if get_foo's argument is optional, a pointer acts like an optional reference.

In this case, the return value is a raw pointer. If it returns an owned resource, it should usually be instead a std::unique_ptr<Foo>* -- a smart pointer at that level of indirection.

If instead, it is returning a pointer to something it does not share ownership of, then a raw pointer makes more sense.

There are other uses for Foo** besides these "crude out parameters". If you have a polymorphic non-value type, non-owning handles are Foo*, and the same reason why you'd want to have an int* you would want to have a Foo**.

Which then leads you to ask "why do you want an int*?" In modern C++ int* is a non-owning nullable mutable reference to an int. It behaves better when stored in a struct than a reference does (references in structs generate confusing semantics around assignment and copy, especially if mixed with non-references).

You could sometimes replace int* with std::reference_wrapper<int>, well std::optional<std::reference_wrapper<int>>, but note that is going to be 2x as large as a simple int*.

So there are legitimate reasons to use int*. Once you have that, you can legitimately use Foo** when you want a pointer to a non-value type. You can even get to int** by having a contiguous array of int*s you want to operate on.

Legitimately getting to three-star programmer gets harder. Now you need a legitimate reason to (say) want to pass a Foo** by indirection. Usually long before you reach that point, you should have considered abstracting and/or simplifying your code structure.

All of this ignores the most common reason; interacting with C APIs. C doesn't have unique_ptr, it doesn't have span. It tends to use primitive types instead of structs because structs require awkward function based access (no operator overloading).

So when C++ interacts with C, you sometimes get 0-3 more *s than the equivalent C++ code would.