- 1 Smart Pointers 101
- 2 The Deal
- 3 Storage of Smart Pointers
- 4 Smart Pointer Member Functions
- 5 Ownership Handling Strategies
- 6 The Address-of Operator
- 7 Implicit Conversion to Raw Pointer Types
- 8 Equality and Inequality
- 9 Ordering Comparisons
- 10 Checking and Error Reporting
- 11 Smart Pointers to const and const Smart Pointers
- 12 Arrays
- 13 Smart Pointers and Multithreading
- 14 Putting It All Together
- 15 Summary
- 16 SmartPtr Quick Facts
This chapter is from the book
This chapter is from the book
This chapter is from the book
7.10 Checking and Error Reporting
Applications need various degrees of safety from smart pointers. Some programs are computation-intensive and must be optimized for speed, whereas some others (actually, most) are input/output intensive, which allows better runtime checking without degrading performance.
Most often, right inside an application, you might need both models: low safety/high speed in some critical areas, and high safety/lower speed elsewhere.
We can divide checking issues with smart pointers into two categories: initialization checking and checking before dereference.
7.10.1 Initialization Checking
Should a smart pointer accept the null (zero) value?
It is easy to implement a guarantee that a smart pointer cannot be null, and it may be very useful in practice. It means that any smart pointer is always valid (unless you fiddle with the raw pointer by using GetImplRef). The implementation is easy with the help of a constructor that throws an exception if passed a null pointer.
template <class T>
class SmartPtr
{
public:
SmartPtr(T* p) : pointee_(p)
{
if (!p) throw NullPointerException();
}
...
};
On the other hand, the null value is a convenient "not a valid pointer" placeholder and can often be useful.
Whether to allow null values affects the default constructor, too. If the smart pointer doesn't allow null values, then how would the default constructor initialize the raw pointer? The default constructor could be lacking, but that would make smart pointers harder to deal with. For example, what should you do when you have a SmartPtr member variable but don't have an appropriate initializer for it at construction time? In conclusion, customizing initialization involves providing an appropriate default value.
7.10.2 Checking Before Dereference
Checking before dereference is important because dereferencing the null pointer engenders undefined behavior. For many applications, undefined behavior is not acceptable, so checking the pointer for validity before dereference is the way to go. Checks before dereference belong to SmartPtr's operator-> and unary operator*.
In contrast to the initialization check, the check before dereference can become a major performance bottleneck in your application, because typical applications use (dereference) smart pointers much more often than they create smart pointer objects. Therefore, you should keep a balance between safety and speed. A good rule of thumb is to start with rigorously checked pointers and remove checks from selected smart pointers as profiling demonstrates a need for it.
Can initialization checking and checking before dereference be conceptually separated? No, because there are links between them. If you enforce strict checking upon initialization, then checking before dereference becomes redundant because the pointer is always valid.
7.10.3 Error Reporting
The only sensible choice for reporting an error is to throw an exception.
You can do something in the sense of avoiding errors. For example, if a pointer is null upon dereference, you can initialize it on the fly. This is a valid and valuable strategy called lazy initialization—you construct the value only when you first need it.
If you want to check things only during debugging, you can use the standard assert or similar, more sophisticated macros. The compiler ignores the tests in release mode, so, assuming you remove all null pointer errors during debugging, you reap the advantages of both checking and speed.
SmartPtr migrates checking to a dedicated Checking policy. This policy implements checking functions (which can optionally provide lazy initialization) and the error reporting strategy.