3 ms·

Thanks for the link and the detailed explanation. This confuses me a bit: > SaferCPlusPlus does not restrict the number and type of references to an object tha

Thanks for the link and the detailed explanation. This confuses me a bit: > SaferCPlusPlus does not restrict the number and type of references to an object that can exist at one time (i.e. the exclusivity of mutable references) and > SaferCPlusPlus .. deals with this issue by having the pointer/reference itself "know" if its target dynamic object is still valid. It sounds like this happens at runtime (reference counting?), as opposed to compile time. Do I understand that correctly? Also, I see that there is the `access requester` type, are there any facilities like Send/Sync in Rust which guard against data races at compile time or runtime? Thanks in advance!

duneroadrunner 9y ago
Well, the "scope" pointers, which roughly correspond to Rust's "non-mut" (i.e. non-retargetable) references and are generally the most commonly used pointer/reference type, don't have any run-time overhead. By their nature, as long as they exist, so does their target. You don't need a sophisticated borrow checker to ensure it. "Mut" (i.e. retargetable) references, on the other hand, do require a borrow checker to ensure, at compile-time, that their target will outlive them. Since SaferCPlusPlus does not have a borrow checker (yet), you'd have to use "registered" pointers, which do have run-time overhead. But in practice, retargetable references are generally much less common than non-retargetable ones (particularly in inner loops), so there tends not to be much effect on performance. SaferCPlusPlus does not yet have an exact analogy to Send/Sync. But as I understand it, those are basically just indicators that say "Trust me, this object is safe to send to / share with other threads." without any verification of the proclaimed safety. At the moment, SaferCPlusPlus does something functionally similar by providing the "TAsyncSharedObjectThatYouAreSureHasNoUnprotectedMutablesReadWriteAccessRequester" which basically allows you to make the same claim about the safe shareability of the object. (And has an unwieldy name to remind you of the seriousness of the claim.) Basically the rule of thumb is "Don't share any object that contains pointers/references/iterators (or is declared "mutable" in C++) or has any (non-static) member functions that return pointers/references/iterators." Rust and SaferCPlusPlus maybe take different positions on whether sharing objects between threads should be encouraged with abandon, or done prudently and only as necessary.
- duneroadrunner 9y ago
  Sorry, I don't think I was thinking very clearly for the last part. I think you're right, the missing Send/Sync functionality is one of the areas where SaferCPlusPlus is still lacking.
  - bluejekyll 9y ago
    You're not wrong that Rust is "trusting" the developer. But in most situations this is the same as any developer claiming that they've written a thread safe type. Rust's type system just guarantees that you have declared these things to be true, which at a high level gives you a lot of confidence. Thanks for the details, much appreciated!

duneroadrunner 9y ago

Well, the "scope" pointers, which roughly correspond to Rust's "non-mut" (i.e. non-retargetable) references and are generally the most commonly used pointer/reference type, don't have any run-time overhead. By their nature, as long as they exist, so does their target. You don't need a sophisticated borrow checker to ensure it. "Mut" (i.e. retargetable) references, on the other hand, do require a borrow checker to ensure, at compile-time, that their target will outlive them. Since SaferCPlusPlus does not have a borrow checker (yet), you'd have to use "registered" pointers, which do have run-time overhead. But in practice, retargetable references are generally much less common than non-retargetable ones (particularly in inner loops), so there tends not to be much effect on performance. SaferCPlusPlus does not yet have an exact analogy to Send/Sync. But as I understand it, those are basically just indicators that say "Trust me, this object is safe to send to / share with other threads." without any verification of the proclaimed safety. At the moment, SaferCPlusPlus does something functionally similar by providing the "TAsyncSharedObjectThatYouAreSureHasNoUnprotectedMutablesReadWriteAccessRequester" which basically allows you to make the same claim about the safe shareability of the object. (And has an unwieldy name to remind you of the seriousness of the claim.) Basically the rule of thumb is "Don't share any object that contains pointers/references/iterators (or is declared "mutable" in C++) or has any (non-static) member functions that return pointers/references/iterators." Rust and SaferCPlusPlus maybe take different positions on whether sharing objects between threads should be encouraged with abandon, or done prudently and only as necessary.

duneroadrunner 9y ago
Sorry, I don't think I was thinking very clearly for the last part. I think you're right, the missing Send/Sync functionality is one of the areas where SaferCPlusPlus is still lacking.
- bluejekyll 9y ago
  You're not wrong that Rust is "trusting" the developer. But in most situations this is the same as any developer claiming that they've written a thread safe type. Rust's type system just guarantees that you have declared these things to be true, which at a high level gives you a lot of confidence. Thanks for the details, much appreciated!