3 ms·
The issue that's trying to be solved with std::launder is essentially around lifetime issues, which strict provenance doesn't really solve. Strict pointer prove
by jcranmer 3y ago
The issue that's trying to be solved with std::launder is essentially around lifetime issues, which strict provenance doesn't really solve. Strict pointer provenance is about fixing the semantics of int-to-pointer, which requires tweaks to pointer-to-int. std::launder, by contrast, is trying to fix cases where memory is being validly reused after the language thinks the object is dead--it's the kind of thing you might need to use to implement an allocator, for example, although you already have screwy effective type rules breaking you that std::launder doesn't fix.
- amluto 3y agoMy point, which may or may not be entirely correct, is that the examples I've seen are, in effect, uses after a lifetime is over. They seem to boil down to something like: struct A { const int x; }; A *ptr = <address of object 1> ... destroy object 1 and create object 2 in its place, so <old address of object 1> == <new address of object 2> do_something_with(ptr->x); The language thinks ptr points to object 1, but it actually points to object 2. In a weak provenance model, maybe this is valid, and it gets the correct results if std::launder is used. But it seems to me that, in a strict provenance model, accessing ptr->x is incorrect -- ptr has provenance for object 1, and object 1 is gone. The operation needed to restore access isn't something very generic like std::launder -- it's specifically the creation of a new pointer with provenance matching object 2. So you don't want: do_something_with(std::launder(ptr->x)); You want (very pseudo-codeish): do_something_with(with_addr(&object2, ptr)->x); And I would hope that a good provenance implementation would not require an abomination like: do_something_with(launder(with_addr(&object2, ptr))->x);