Unchecked access ban

Anyone tried to ban unsafe access operations (like operator* for pointers) from the codebase and replace them with custom functions? The purpose would be to replace UB with an exception and/or to provide more debug information (like file, line or stack-trace) when invalid access happens. For example, custom de-referencing function for pointers could look like this:

template<class T> T& value(T* ptr, std::source_location sl = std::source_location::current())
{
    If (ptr) return *ptr;
    throw std::runtime_error(std::format(“bad access in {}:{}:{}”, sl.file_name(), sl.line(), sl.column()));
    // error log could also be printed. It could contain stacktrace.
}

Something similar could be implemented for smart pointers, optionals, variants, vector::front etc.
Unchecked access ban could then be enforced by static analyzer like clang TIDY.
Additionally the unsafe() function could be provided for use in some performance critical parts - it would terminate on invalid access in debug build, but wouldn't check validity in release build.

Can anyone see any problem with this scheme? Compilation times? Performance? Verbosity? Or maybe there is a better solution?

EDIT: I will try to clarify few things:

1. I didn’t intend to fix all memory issues here, only unchecked access – nullptr dereference, std::nullopt dereference, some index out of bounds issues etc. (I guess I shouldn’t call it “unsafe access”)
2. My code base has millions of LoC. Rewriting it in a different language is impossible.
3. Checks should be run in release build as well, unless unsafe() function is used instead of value().
4. I prefer expectation to crash because system could recover from exception - It is possible to remove the client that triggered the bug.
5. Even if operating system would crash the app on nullptr dereference the compiler optimizations could rewrite the code, so that some unpredictable behavior would happen instead.
6. std::optional wont crash on nullopt dereference - it will cause hard to predict problems.

The biggest issue I see with your approach is that it is not that useful. A pointer that equals nullptr is the easy bug. The more common and more difficult to track down bugs is other invalid pointers.

For example (poor code, just for the sake of the example it does have a bug!):

struct foo { int value = 42; };

struct bar { foo* f; };

int main() {
   bar b;
   {
       foo f; 
       b.f = &f;
   }
   return b.f->value; // UNDEFINED ! Dereferencing a dangling pointer
}

b.f is a dangling pointer. Smart pointers aside, there is no clean way to set b.f to nullptr when the object it points to ends its lifetime. It is not possible to know if b.f is a valid pointer. The way out is to not get into this situation in the first place by using smart pointers.

You can use a function like your value to add debug logs with file, and line number to catch nullptr dereferences (and with smart pointers is will also catch most dereference of invalid smart pointers). However, you need to consider that you should not use it always. It adds overhead which is often unwanted. For example with a smart pointer ptr:

  for (const auto& element : some_container) {
      e(*ptr);
  }

You do not want to check in every iteration that the pointer is valid.