3 ms·

Not sure what to make of this. Is this a feature, or a whole design? The idea here is simply that if the whole call tree can be examined, rather than only look

Not sure what to make of this. Is this a feature, or a whole design? The idea here is simply that if the whole call tree can be examined, rather than only looking at one module at a time, less annotation is needed. That's reasonable enough, although it may result in long compile times. What I don't see here is: - How are circular references handled? - C++ objects implicitly have links from parent to child and child to parent. So there's built-in circularity. How does that work? - What about interior mutability? Examining the whole call tree is useful. It allows catching mutex deadlocks where a thread locks against itself and stalls. It may be possible to replace something like Rust's RefCell with something, perhaps "SafeCell", that supports the same .borrow() and .borrow_mut operations, checking them at compile time for overlapping borrow scopes.

j16sdiz 2y ago
> - C++ objects implicitly have links from parent to child and child to parent. So there's built-in circularity. How does that work? Can you elaborate? In my understand, the parent/child relation are on the class not the object itself.
- Animats 2y ago
  A child class can reference fields in the parent, and the parent can call virtual functions in the child.
  - carlmr 2y ago
    You mean vtable for inheritance? There's no ownership relation here.
    - jcelerier 2y ago
      Well, there is: it's easy to trigger unsafe behaviour by calling a virtual method accessing a child class data member (say some std::vector) when in the parent class destructor, as the child sub object will already have been destroyed. Thus it's reasonable to say that there is a bidirectional ownership relationship.
      - Animats 2y ago
        Yes. Rust has safe destructor semantics. C++ does not. Back references are really hard in Rust. You can do them with Rc, RefCell, and Weak, but there's a lot of run-time checking involved. More static analysis could eliminate most of that run-time checking. .borrow(), .borrow_mut(), and .upgrade().unwrap() panic if they ever fail. So you really want to prove they can't fail. If you can do that, you don't need the run-time checks. In that direction lies the solution to Rust's limited data structure problems.
      - messe 2y ago
        When in the parent class destructor, the v-table will point toward the parent's v-table not the child's (try it out), so I'm not sure how you'd call a virtual method accessing a child member.
        bregma 2y ago
        Would it? Or is it undefined? No C++ runtime I know of will generate a new, different vtbl just to switch it out when invoking the non-owning base class destructor on an object. Nor am I familiar with any part of the C++ stnadrd that mandates this behaviour, or even mandates vtbls.
        gpderetta 2y ago
        It doesn't create a new vtbl, when invoking the base object destructor it just repoints the current vtable ptr to the base object vtable as first thing: https://godbolt.org/z/MKx6oTE63 I can't recite chapter and verse, but I'm pretty sure that's mandated by the standard and it mirrors the behaviour in the constructor. Or you meant something else?
        112233 2y ago
        Of course it would, not a lot would run otherwise. Here is very nice writeup about vtables and constructors: https://shaharmike.com/cpp/vtable-part4/ https://shaharmike.com/cpp/vtable-part4/
        nemetroid 2y ago
- deleted 2y ago
  [deleted]
aw1621107 2y ago
> Not sure what to make of this. Is this a feature, or a whole design? My (high-level) understanding is that this is a response to some feedback [1, 2] to the author's previous paper [0] which (very generally speaking) adds some Rust-like systems/semantics to C++ to achieve memory safety. Some commenters voiced disapproval of the need for lifetime annotations and expressed a desire to find a solution that doesn't require them. I think this paper is an exploration of that idea to see what can be achieved without lifetime annotations. [0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3444r0.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p34... [1]: https://old.reddit.com/r/cpp/comments/1ffgz49/safe_c_language_extensions_for_memory_safety/ https://old.reddit.com/r/cpp/comments/1ffgz49/safe_c_languag... [2]: https://old.reddit.com/r/cpp/comments/1fiuhb7/the_empire_of_c_strikes_back_with_safe_c_proposal/ https://old.reddit.com/r/cpp/comments/1fiuhb7/the_empire_of_...
einpoklum 2y ago
Whole new design which Sean Baxter suggests the committee foist upon C++. Being a continuation of "safe C++", it seems to be part of coping with the challenge of the popularity of Rust - and perhaps even more with how some lobbyists have gotten the US government to adopt some decisions against using "memory-unsafe languages". Just remember that WG21 papers are their authors' position/claims, not the committee's or the community's, unless accepted. I think, or rather hope, this is not accepted.

j16sdiz 2y ago

> - C++ objects implicitly have links from parent to child and child to parent. So there's built-in circularity. How does that work? Can you elaborate? In my understand, the parent/child relation are on the class not the object itself.

Animats 2y ago
A child class can reference fields in the parent, and the parent can call virtual functions in the child.
- carlmr 2y ago
  You mean vtable for inheritance? There's no ownership relation here.
  - jcelerier 2y ago
    Well, there is: it's easy to trigger unsafe behaviour by calling a virtual method accessing a child class data member (say some std::vector) when in the parent class destructor, as the child sub object will already have been destroyed. Thus it's reasonable to say that there is a bidirectional ownership relationship.
    - Animats 2y ago
      Yes. Rust has safe destructor semantics. C++ does not. Back references are really hard in Rust. You can do them with Rc, RefCell, and Weak, but there's a lot of run-time checking involved. More static analysis could eliminate most of that run-time checking. .borrow(), .borrow_mut(), and .upgrade().unwrap() panic if they ever fail. So you really want to prove they can't fail. If you can do that, you don't need the run-time checks. In that direction lies the solution to Rust's limited data structure problems.
    - messe 2y ago
      When in the parent class destructor, the v-table will point toward the parent's v-table not the child's (try it out), so I'm not sure how you'd call a virtual method accessing a child member.
      - bregma 2y ago
        Would it? Or is it undefined? No C++ runtime I know of will generate a new, different vtbl just to switch it out when invoking the non-owning base class destructor on an object. Nor am I familiar with any part of the C++ stnadrd that mandates this behaviour, or even mandates vtbls.
        gpderetta 2y ago
        It doesn't create a new vtbl, when invoking the base object destructor it just repoints the current vtable ptr to the base object vtable as first thing: https://godbolt.org/z/MKx6oTE63 I can't recite chapter and verse, but I'm pretty sure that's mandated by the standard and it mirrors the behaviour in the constructor. Or you meant something else?
        112233 2y ago
        Of course it would, not a lot would run otherwise. Here is very nice writeup about vtables and constructors: https://shaharmike.com/cpp/vtable-part4/ https://shaharmike.com/cpp/vtable-part4/
        nemetroid 2y ago
deleted 2y ago
[deleted]

aw1621107 2y ago

> Not sure what to make of this. Is this a feature, or a whole design? My (high-level) understanding is that this is a response to some feedback [1, 2] to the author's previous paper [0] which (very generally speaking) adds some Rust-like systems/semantics to C++ to achieve memory safety. Some commenters voiced disapproval of the need for lifetime annotations and expressed a desire to find a solution that doesn't require them. I think this paper is an exploration of that idea to see what can be achieved without lifetime annotations. [0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3444r0.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p34... [1]: https://old.reddit.com/r/cpp/comments/1ffgz49/safe_c_language_extensions_for_memory_safety/ https://old.reddit.com/r/cpp/comments/1ffgz49/safe_c_languag... [2]: https://old.reddit.com/r/cpp/comments/1fiuhb7/the_empire_of_c_strikes_back_with_safe_c_proposal/ https://old.reddit.com/r/cpp/comments/1fiuhb7/the_empire_of_...

einpoklum 2y ago

Whole new design which Sean Baxter suggests the committee foist upon C++. Being a continuation of "safe C++", it seems to be part of coping with the challenge of the popularity of Rust - and perhaps even more with how some lobbyists have gotten the US government to adopt some decisions against using "memory-unsafe languages". Just remember that WG21 papers are their authors' position/claims, not the committee's or the community's, unless accepted. I think, or rather hope, this is not accepted.