4 ms·

> C++ is commonly used in contexts where object lifetimes and ownership are inherently unknowable at compile-time What specific contexts are these?

by orf 2y ago

jandrewrogers 2y ago
For example, anything that pages live objects to disk from user space. This is a common feature of high-performance/high-scale database engines and other data intensive software. Modern storage is larger than the addressable virtual memory supported by silicon so you can't mmap() it, and even if you could you wouldn't want to because using virtual memory is significantly slower than doing it from user space. A single memory address can contain several unrelated live objects depending on when you look; a single live object can appear at different memory addresses over its lifetime without being moved; and live objects may not have a memory address at all. The hardware implicitly owns read and write references to these objects, which are not visible to the compiler and free to ignore the ownership model. Consequently, you need a way to tell the compiler that the object it thinks exists at an address no longer does, and that object has neither been moved nor destroyed, and that there may be an unrelated object at that address that was never constructed. In these cases, compiler optimizations can generate incorrect code based on a naive analysis based on what is visible at compile-time. C++ provides ways to give this a defined behavior and indicate to the compiler when its lifetime model is incomplete so that it doesn't produce incorrect code. You can build ownership models on top of this that incorporate ownership that is not visible at compile-time. Some C++ devs don't know these features exist, other C++ devs use them routinely. But the point is that C++ has specific features to address the case when lifetime analysis cannot be correctly done by the compiler.
- pcwalton 2y ago
  Userspace-paged data is a tiny fraction of the amount of data that C++ programs, taken as a whole, process, and is a very weak argument for dropping static memory safety. Besides, because of unsafe, any Rust-like language, like Circle C++, will have the features needed to deal with such data too.
- nextaccountic 2y ago
  > Modern storage is larger than the addressable virtual memory supported by silicon so you can't mmap() it Larger than the 48 bits address space of most 64 bits architectures?
  - chuckadams 2y ago
    48 bits is “only” 256 terabytes. Totally possible to max that nowadays.
- LegionMammal978 2y ago
  > Consequently, you need a way to tell the compiler that the object it thinks exists at an address no longer does, and that object has neither been moved nor destroyed, and that there may be an unrelated object at that address that was never constructed. If anything, Rust is even more expressive than C++ in this regard: it has no concept at all of "an object at an address". You can (unsafely) cast a pointer from any type to any other type and read it, as long as the underlying memory is properly initialized. And if you're in a context where you know it will always be valid, or if you can check the validity at runtime, you can put a safe wrapper over the conversion. For instance, the safe function str::from_utf8() converts a byte-array pointer into a string pointer, after checking that the encoding is correct. Nothing in memory is changed, and the old and new pointers form two different views that can be used simultaneously. And it's not magic: you could copy its implementation yourself, and your function would be just as valid as the standard-library version. Contrast with C++, where all memory must have one single type at any time, regardless of how much laundering you do. The only kinds of semantic "ownership" in Rust are access restrictions caused by the aliasing rules (which just depend on the pointers in use, not on objects in memory), and local variables and temporaries being dropped at the end of their scope (if they haven't been moved elsewhere). All the high-level lifetime rules of safe Rust are built on top of those semantic rules, and a smidgeon of unsafe Rust can subvert them as necsssary.

> C++ is commonly used in contexts where object lifetimes and ownership are inherently unknowable at compile-time What specific contexts are these?

by orf 2y ago

> C++ is commonly used in contexts where object lifetimes and ownership are inherently unknowable at compile-time What specific contexts are these?

jandrewrogers 2y ago

For example, anything that pages live objects to disk from user space. This is a common feature of high-performance/high-scale database engines and other data intensive software. Modern storage is larger than the addressable virtual memory supported by silicon so you can't mmap() it, and even if you could you wouldn't want to because using virtual memory is significantly slower than doing it from user space. A single memory address can contain several unrelated live objects depending on when you look; a single live object can appear at different memory addresses over its lifetime without being moved; and live objects may not have a memory address at all. The hardware implicitly owns read and write references to these objects, which are not visible to the compiler and free to ignore the ownership model. Consequently, you need a way to tell the compiler that the object it thinks exists at an address no longer does, and that object has neither been moved nor destroyed, and that there may be an unrelated object at that address that was never constructed. In these cases, compiler optimizations can generate incorrect code based on a naive analysis based on what is visible at compile-time. C++ provides ways to give this a defined behavior and indicate to the compiler when its lifetime model is incomplete so that it doesn't produce incorrect code. You can build ownership models on top of this that incorporate ownership that is not visible at compile-time. Some C++ devs don't know these features exist, other C++ devs use them routinely. But the point is that C++ has specific features to address the case when lifetime analysis cannot be correctly done by the compiler.

pcwalton 2y ago
Userspace-paged data is a tiny fraction of the amount of data that C++ programs, taken as a whole, process, and is a very weak argument for dropping static memory safety. Besides, because of unsafe, any Rust-like language, like Circle C++, will have the features needed to deal with such data too.
nextaccountic 2y ago
> Modern storage is larger than the addressable virtual memory supported by silicon so you can't mmap() it Larger than the 48 bits address space of most 64 bits architectures?
- chuckadams 2y ago
  48 bits is “only” 256 terabytes. Totally possible to max that nowadays.
LegionMammal978 2y ago
> Consequently, you need a way to tell the compiler that the object it thinks exists at an address no longer does, and that object has neither been moved nor destroyed, and that there may be an unrelated object at that address that was never constructed. If anything, Rust is even more expressive than C++ in this regard: it has no concept at all of "an object at an address". You can (unsafely) cast a pointer from any type to any other type and read it, as long as the underlying memory is properly initialized. And if you're in a context where you know it will always be valid, or if you can check the validity at runtime, you can put a safe wrapper over the conversion. For instance, the safe function str::from_utf8() converts a byte-array pointer into a string pointer, after checking that the encoding is correct. Nothing in memory is changed, and the old and new pointers form two different views that can be used simultaneously. And it's not magic: you could copy its implementation yourself, and your function would be just as valid as the standard-library version. Contrast with C++, where all memory must have one single type at any time, regardless of how much laundering you do. The only kinds of semantic "ownership" in Rust are access restrictions caused by the aliasing rules (which just depend on the pointers in use, not on objects in memory), and local variables and temporaries being dropped at the end of their scope (if they haven't been moved elsewhere). All the high-level lifetime rules of safe Rust are built on top of those semantic rules, and a smidgeon of unsafe Rust can subvert them as necsssary.