Avoiding Raw Pointers

In modern C++ programming, it's generally recommended to avoid raw pointers for several reasons related to safety, clarity, and maintainability.

Raw pointers do not manage memory automatically. This puts the onus on us as developers to ensure the lifecycles of our objects are managed correctly. If we don't accomplish thise, our program can have several problems.

Memory Leaks

If you forget to call delete on a dynamically allocated object, you'll leak memory. For example:

1void LeakyFunction() {
2  int* p = new int(42); 
3  // Missing delete
4}

Here, the allocated memory is not freed, leading to a memory leak.

Dangling Pointers

After delete is called, the pointer still holds the address of the freed memory, which can lead to undefined behavior if accessed.

1void DanglingFunction() {
2  int* p = new int(42);
3  delete p;
4  *p = 10; 
5}

Raw pointers can make code harder to understand and maintain:

• Manual Management: You must manually manage the allocation and deallocation, increasing the likelihood of bugs.
• Ownership Semantics: It's not always clear who owns the memory or who is responsible for deleting it, making it difficult to manage lifetimes and ownership.

Modern C++ provides smart pointers like std::unique_ptr and std::shared_ptr that handle memory management automatically.

std::unique_ptr

This manages a resource with exclusive ownership, ensuring the resource is deleted when the unique_ptr goes out of scope.

1void SafeFunction() {
2  std::unique_ptr<int> p{
3    std::make_unique<int>(42)};
4}

Here, the memory is automatically freed when p goes out of scope.

std::shared_ptr

This manages a resource with shared ownership, deleting the resource only when the last shared_ptr to it is destroyed.

1void SharedFunction() {
2  std::shared_ptr<int> p1{
3    std::make_shared<int>(42)};
4
5  // Both share ownership
6  std::shared_ptr<int> p2{p1};
7}

Using smart pointers helps avoid common pitfalls with raw pointers and makes your code safer and easier to manage.