5 ms·

> You can't generally replace pointers with references either. If this were generally true, I would expect to see a lot more use of pointers than references in

> You can't generally replace pointers with references either. If this were generally true, I would expect to see a lot more use of pointers than references in c++ code, but in practice it's the exact opposite--it's rare that one needs to use a pointer rather than reference. Basically only if it needs to be able to be null or if it needs to be able to be modified.

tsimionescu 4y ago
In C code, you'll find many uses of pointers for iteration, which can't be replaced with C++ references. C++ typically also uses pointers in these cases, but wraps them in a layer of iterator templates (that is, hopefully, optimized out into a raw pointer access). Not to mention, references obscure the difference between copying an object and sending its address at the call site, and obscure the difference between accessing a local object and a pointed-to object at the access site - a major disadvantage compared to pointers. Especially for a project which heavily uses email patches for code review and discussion. Also, there are programming errors that can lead to a NULL reference, and there is no way to guard against that in code using the reference (well, none that doesn't generate Warnings, and/or is liable to be optimized out) - whereas at least with pointers you can always check in your own code.
- fluoridation 4y ago
  Note that I was talking about using pointers to pass a single object by reference. In such cases references are 100% better than pointers, if the pointer is never supposed to be null. >Also, there are programming errors that can lead to a NULL reference, and there is no way to guard against that in code using the reference (well, none that doesn't generate Warnings, and/or is liable to be optimized out) - whereas at least with pointers you can always check in your own code. On the other hand, if you find you've received a null reference as a parameter then you know that something has definitely gone wrong, because unlike with pointers null references are impossible in the absence of UB. If all you know is that the function has received a null pointer then you could waste a lot of time trying to figure out how the program reached that state, when in actuality the problem is that someone else wrote out of bounds.
- usefulcat 4y ago
  > In C code, you'll find many uses of pointers for iteration, which can't be replaced with C++ references. In c++, ranged for loops are both far more common and idiomatic for iteration, and will compile to the most efficient form possible. At least for gcc and clang, you definitely don't have to 'hope' that they will be optimized to the equivalent pointer-based code--they will be. > ... whereas at least with pointers you can always check in your own code. Regarding null references -- the only way for that to happen is by dereferencing a null pointer, which of course is equally invalid with or without references. BUT: if all you have is pointers, then--all else being equal--you will have many more places where you may need to check whether a pointer is null. Once you've converted a pointer to a reference by dereferencing it, you (and the compiler) can legitimately assume that it's never null. If you ever encounter a 'null reference', the problem is never with the reference, it's always guaranteed to be with a deference somewhere higher up the stack. As a result, when references are available and preferred, there are not nearly as many places where you have to decide whether to check for null in the first place.

tsimionescu 4y ago

In C code, you'll find many uses of pointers for iteration, which can't be replaced with C++ references. C++ typically also uses pointers in these cases, but wraps them in a layer of iterator templates (that is, hopefully, optimized out into a raw pointer access). Not to mention, references obscure the difference between copying an object and sending its address at the call site, and obscure the difference between accessing a local object and a pointed-to object at the access site - a major disadvantage compared to pointers. Especially for a project which heavily uses email patches for code review and discussion. Also, there are programming errors that can lead to a NULL reference, and there is no way to guard against that in code using the reference (well, none that doesn't generate Warnings, and/or is liable to be optimized out) - whereas at least with pointers you can always check in your own code.

fluoridation 4y ago
Note that I was talking about using pointers to pass a single object by reference. In such cases references are 100% better than pointers, if the pointer is never supposed to be null. >Also, there are programming errors that can lead to a NULL reference, and there is no way to guard against that in code using the reference (well, none that doesn't generate Warnings, and/or is liable to be optimized out) - whereas at least with pointers you can always check in your own code. On the other hand, if you find you've received a null reference as a parameter then you know that something has definitely gone wrong, because unlike with pointers null references are impossible in the absence of UB. If all you know is that the function has received a null pointer then you could waste a lot of time trying to figure out how the program reached that state, when in actuality the problem is that someone else wrote out of bounds.
usefulcat 4y ago
> In C code, you'll find many uses of pointers for iteration, which can't be replaced with C++ references. In c++, ranged for loops are both far more common and idiomatic for iteration, and will compile to the most efficient form possible. At least for gcc and clang, you definitely don't have to 'hope' that they will be optimized to the equivalent pointer-based code--they will be. > ... whereas at least with pointers you can always check in your own code. Regarding null references -- the only way for that to happen is by dereferencing a null pointer, which of course is equally invalid with or without references. BUT: if all you have is pointers, then--all else being equal--you will have many more places where you may need to check whether a pointer is null. Once you've converted a pointer to a reference by dereferencing it, you (and the compiler) can legitimately assume that it's never null. If you ever encounter a 'null reference', the problem is never with the reference, it's always guaranteed to be with a deference somewhere higher up the stack. As a result, when references are available and preferred, there are not nearly as many places where you have to decide whether to check for null in the first place.