Skip to main content

Distinguish between pointers and references.

Item 1: Distinguish between pointers and references.
Pointers and references look different enough (pointers use the "*" and "->" operators, references use "."), but
they seem to do similar things. Both pointers and references let you refer to other objects indirectly. How, then,
do you decide when to use one and not the other?
First, recognize that there is no such thing as a null reference. A reference must always refer to some object. As
a result, if you have a variable whose purpose is to refer to another object, but it is possible that there might not
be an object to refer to, you should make the variable a pointer, because then you can set it to null. On the other
hand, if the variable must always refer to an object, i.e., if your design does not allow for the possibility that the
variable is null, you should probably make the variable a reference.
"But wait," you wonder, "what about underhandedness like this?"
char *pc = 0;
char& rc = *pc;
// set pointer to null
// make reference refer to
// dereferenced null pointer
Well, this is evil, pure and simple. The results are undefined (compilers can generate output to do anything they
like), and people who write this kind of code should be shunned until they agree to cease and desist. If you have
to worry about things like this in your software, you're probably best off avoiding references entirely. Either that
or finding a better class of programmers to work with. We'll henceforth ignore the possibility that a reference
can be "null."
Because a reference must refer to an object, C++ requires that references be initialized:
string& rs;
// error! References must
// be initialized
string s("xyzzy");
string& rs = s;
// okay, rs refers to s
Pointers are subject to no such restriction:
string *ps;
// uninitialized pointer:
// valid but risky
The fact that there is no such thing as a null reference implies that it can be more efficient to use references than
to use pointers. That's because there's no need to test the validity of a reference before using it:
void printDouble(const double& rd)
{
cout << rd;
}
// no need to test rd; it
// must refer to a double
Pointers, on the other hand, should generally be tested against null:
void printDouble(const double *pd)
{
if (pd) {
cout << *pd;
}
// check for null pointer
}
Another important difference between pointers and references is that pointers may be reassigned to refer to
different objects. A reference, however, always refers to the object with which it is initialized:
string s1("Nancy");
string s2("Clancy");
string& rs = s1; // rs refers to s1
string *ps = &s1; // ps points to s1

rs = s2; // rs still refers to s1,
        // but s1's value is now
       // "Clancy"
ps = &s2; // ps now points to s2;
         // s1 is unchanged
In general, you should use a pointer whenever you need to take into account the possibility that there's nothing to
refer to (in which case you can set the pointer to null) or whenever you need to be able to refer to different
things at different times (in which case you can change where the pointer points). You should use a reference
whenever you know there will always be an object to refer to and you also know that once you're referring to
that object, you'll never want to refer to anything else.
There is one other situation in which you should use a reference, and that's when you're implementing certain
operators. The most common example is operator[]. This operator typically needs to return something that can
be used as the target of an assignment:
vector v(10);
v[5] = 10;
// create an int vector of size 10;
// vector is a template in the
// standard C++ library (see Item 35)
// the target of this assignment is
// the return value of operator[]
If operator[] returned a pointer, this last statement would have to be written this way:
*v[5] = 10;
But this makes it look like v is a vector of pointers, which it's not. For this reason, you'll almost always want
operator[] to return a reference. (For an interesting exception to this rule, see Item 30.)
References, then, are the feature of choice when you know you have something to refer to, when you'll never
want to refer to anything else, and when implementing operators whose syntactic requirements make the use of
pointers undesirable. In all other cases, stick with pointers.

Comments

Popular posts from this blog

CKA Simulator Kubernetes 1.22

  https://killer.sh Pre Setup Once you've gained access to your terminal it might be wise to spend ~1 minute to setup your environment. You could set these: alias k = kubectl                         # will already be pre-configured export do = "--dry-run=client -o yaml"     # k get pod x $do export now = "--force --grace-period 0"   # k delete pod x $now Vim To make vim use 2 spaces for a tab edit ~/.vimrc to contain: set tabstop=2 set expandtab set shiftwidth=2 More setup suggestions are in the tips section .     Question 1 | Contexts Task weight: 1%   You have access to multiple clusters from your main terminal through kubectl contexts. Write all those context names into /opt/course/1/contexts . Next write a command to display the current context into /opt/course/1/context_default_kubectl.sh , the command should use kubectl . Finally write a second command doing the same thing into ...

OWASP Top 10 Threats and Mitigations Exam - Single Select

Last updated 4 Aug 11 Course Title: OWASP Top 10 Threats and Mitigation Exam Questions - Single Select 1) Which of the following consequences is most likely to occur due to an injection attack? Spoofing Cross-site request forgery Denial of service   Correct Insecure direct object references 2) Your application is created using a language that does not support a clear distinction between code and data. Which vulnerability is most likely to occur in your application? Injection   Correct Insecure direct object references Failure to restrict URL access Insufficient transport layer protection 3) Which of the following scenarios is most likely to cause an injection attack? Unvalidated input is embedded in an instruction stream.   Correct Unvalidated input can be distinguished from valid instructions. A Web application does not validate a client’s access to a resource. A Web action performs an operation on behalf of the user without checkin...