Hacker News Reader

Comment by josefx | Hacker News Reader

> The memory model is a flat space provided by the OS that can be addressed by pointers

From what I understand this is not true. Pointers cease to be valid the moment you try to leave a single allocation. You get to play around within a single continuous allocation and one past the end, everything further out is playing with fire.

Even comparing the "addresses" of two separate allocations is undefined if done with "<" . The comparison function std::less is basically magic to get well defined behavior out of a language that doesn't guarantee it.

> C++ is similar to assembly code

Only if you use a compiler that does not optimize anything.

View on HN

> Pointers cease to be valid the moment you try to leave a single allocation.

For the other readers who might not know what this is referring to, it's pointer provenance. For an introduction to the topic, I always recommend Ralf Jung's blog series, "Pointers Are Complicated":

https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html

> everything further out is playing with fire.

That's the point. C and C++ don't prevent you from playing with that for. Memory-safe language do.

Rust only requires you to wrap it in unsafe. And I think C# allows you to do some pretty crazy stuff too.

The Kestrel web server[0] is an example of a codebase that makes extensive use of C#'s unsafe functionality. UnmanagedBufferAllocator[1], for example, looks pretty similar to how you'd write it in C++.

[0] https://github.com/dotnet/aspnetcore/tree/1a56bdb671700ae698...

[1] https://github.com/dotnet/aspnetcore/blob/1a56bdb671700ae698...

C# cleanly separates pointers into Java-style managed references that are opaque, and C-style unmanaged pointers that are transparent but can only be used inside "unsafe" blocks.

It is, for all practical purposes, a flat space in the sense that for bare pointers, operator++ is defined (increments to the next whatever, defined based on type of pointer).

There is no operator++ equivalent in Java to apply to object references (unless you go unsafe); you can't immediately shoot yourself in the foot without the compiler noticing by asking for "the next object after this one" when no such thing exists.

(handwave a bit: of course, you can ask for an object past the last object in any container. That's (a) not the same thing and (b) results in an immediate runtime error in Java, instead of undefined behavior)

Reply on news.ycombinator.com