4 ms·

Thanks! Could you point me to the C++ primitives that prevent cross-thread access of non-thread-safe data? I'd honestly love to learn about this. If it's not a

Thanks! Could you point me to the C++ primitives that prevent cross-thread access of non-thread-safe data? I'd honestly love to learn about this. If it's not asking too much, could you also point me to the C++ primitives that prevent dangling pointers as well? EDIT: Also, the primitives that prevents the mutation of what a const reference refers to? (Much in the way that shared references and exclusive references can't co-exist in Rust)? I'd hope the C++ primitives for the above all perform their job at compile time of course.

jdright 4y ago
He can't because he doesn't understand what you're asking.
- davidatbu 4y ago
  Tbh, I'm also a Rust beginner and know even less about C++, so I'm sincerely trying to learn here.
  - Filligree 4y ago
    C++ doesn’t provide any of the checks being talked about here. There’s nothing much to learn; they just don’t exist.
    - davidatbu 4y ago
      Thank you! Still waiting on you @ncmncm, if you think differently.
      - ncmncm 4y ago
        If you can see it at all, it will be an atomic type.
        davidatbu 4y ago
        I skimmed docs for std::atomic, and I believe what you're suggesting is a super-brief version of what was outlined here[0]. If so, thanks! Through I don't yet "see it" that C++ has safety primitives that "equal" that of Rust's, I've learnt a lot about C++'s safety features from other folks' replies in this thread. So again, thanks! [0] https://news.ycombinator.com/reply?id=32824168 https://news.ycombinator.com/reply?id=32824168
- ncmncm 4y ago
  Trolling is unwelcome here.
NavinF 4y ago
Ignoring GP's trolling, closest would be https://clang.llvm.org/docs/ThreadSafetyAnalysis.html https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
- davidatbu 4y ago
  Thank you! IIUC correctly, the TLDR of that is: An extension to C++ that adds (pretty much) a type system on top of C++ to enable static analysis and prevention of race conditions. Widely used at Google. Super interesting! That's exactly what Rust is doing too, except I think Rust's version (which pretty much relies on two "traits", `Send` and `Sync`) is much simpler, much more ergonomic, and much more complete.
fizzynut 4y ago
By definition you can't safely access "non-thread-safe data" from another thread unless it was already safe to access despite being "non-thread-safe", but there are also many ways to make something thread safe. You can prevent dangling pointers using strong/weak pointers or many other ways depending on the context, most examples are quite contrived though and the only "dangling pointers" I see are usually those relating to resources/handles to things from the OS where the lifetimes need to be managed more carefully, i.e. audio/video/gpu/etc, how would a rust program handle a handle to the currently playing audio device being unplugged and invalidating your handle? Every OS also has its own quirks, so how would it work cross platform? Constexpr primatives/functions have compile time guarantees and can't be changed.
- davidatbu 4y ago
  About the threading stuff, I think I wasn't clear initially. Maybe a rephrasing/simplification of my question will help: Does C++ have a compile-time way of ensuring, say, that mutex-protected data isn't accessed without acquiring a lock on the mutex? > You can prevent dangling pointers using strong/weak pointers I presume you're talking about unique_ptr/shared_ptr/weak_ptr right? If one avoids raw pointers and uses those, I think you cannot have a shared reference without ref counting right? (because shared_ptr uses ref-counting). Not that this invalidates your point, just thought it was useful to point out. > how would a rust program handle a handle to the currently playing audio device being unplugged and invalidating your handle? I've never had to deal with that situation, but I presume some mechanism similar to how the mutex in the stdlib has a .lock() method that returns an Option<MutexGuard<_>> (which forces the user to acknowledge/handle the case of a poisoned mutex). > Constexpr primatives/functions have compile time guarantees and can't be changed. Consider the c++ code here: int a = 4; const int &b = a; a += 1; Such a thing would be disallowed in Rust, which (though hard to see from this example) is the exact mechanism that prevents a Vec being modified while it is being iterated on. Does C++ have primitives that provide such guarantees?
  - fizzynut 4y ago
    Like I said, use constexpr. constexpr int a = 4; auto& b = a; a+= 1; // compile error b+= 1; // compile error Trying to make b constexpr with "a" as an int is also a compile error.

jdright 4y ago

He can't because he doesn't understand what you're asking.

davidatbu 4y ago
Tbh, I'm also a Rust beginner and know even less about C++, so I'm sincerely trying to learn here.
- Filligree 4y ago
  C++ doesn’t provide any of the checks being talked about here. There’s nothing much to learn; they just don’t exist.
  - davidatbu 4y ago
    Thank you! Still waiting on you @ncmncm, if you think differently.
    - ncmncm 4y ago
      If you can see it at all, it will be an atomic type.
      - davidatbu 4y ago
        I skimmed docs for std::atomic, and I believe what you're suggesting is a super-brief version of what was outlined here[0]. If so, thanks! Through I don't yet "see it" that C++ has safety primitives that "equal" that of Rust's, I've learnt a lot about C++'s safety features from other folks' replies in this thread. So again, thanks! [0] https://news.ycombinator.com/reply?id=32824168 https://news.ycombinator.com/reply?id=32824168
ncmncm 4y ago
Trolling is unwelcome here.

NavinF 4y ago

Ignoring GP's trolling, closest would be https://clang.llvm.org/docs/ThreadSafetyAnalysis.html https://clang.llvm.org/docs/ThreadSafetyAnalysis.html

davidatbu 4y ago
Thank you! IIUC correctly, the TLDR of that is: An extension to C++ that adds (pretty much) a type system on top of C++ to enable static analysis and prevention of race conditions. Widely used at Google. Super interesting! That's exactly what Rust is doing too, except I think Rust's version (which pretty much relies on two "traits", `Send` and `Sync`) is much simpler, much more ergonomic, and much more complete.

fizzynut 4y ago

By definition you can't safely access "non-thread-safe data" from another thread unless it was already safe to access despite being "non-thread-safe", but there are also many ways to make something thread safe. You can prevent dangling pointers using strong/weak pointers or many other ways depending on the context, most examples are quite contrived though and the only "dangling pointers" I see are usually those relating to resources/handles to things from the OS where the lifetimes need to be managed more carefully, i.e. audio/video/gpu/etc, how would a rust program handle a handle to the currently playing audio device being unplugged and invalidating your handle? Every OS also has its own quirks, so how would it work cross platform? Constexpr primatives/functions have compile time guarantees and can't be changed.

davidatbu 4y ago
About the threading stuff, I think I wasn't clear initially. Maybe a rephrasing/simplification of my question will help: Does C++ have a compile-time way of ensuring, say, that mutex-protected data isn't accessed without acquiring a lock on the mutex? > You can prevent dangling pointers using strong/weak pointers I presume you're talking about unique_ptr/shared_ptr/weak_ptr right? If one avoids raw pointers and uses those, I think you cannot have a shared reference without ref counting right? (because shared_ptr uses ref-counting). Not that this invalidates your point, just thought it was useful to point out. > how would a rust program handle a handle to the currently playing audio device being unplugged and invalidating your handle? I've never had to deal with that situation, but I presume some mechanism similar to how the mutex in the stdlib has a .lock() method that returns an Option<MutexGuard<_>> (which forces the user to acknowledge/handle the case of a poisoned mutex). > Constexpr primatives/functions have compile time guarantees and can't be changed. Consider the c++ code here: int a = 4; const int &b = a; a += 1; Such a thing would be disallowed in Rust, which (though hard to see from this example) is the exact mechanism that prevents a Vec being modified while it is being iterated on. Does C++ have primitives that provide such guarantees?
- fizzynut 4y ago
  Like I said, use constexpr. constexpr int a = 4; auto& b = a; a+= 1; // compile error b+= 1; // compile error Trying to make b constexpr with "a" as an int is also a compile error.