4 ms·

Are there languages that do SBRM but not RAII?

• codeflo 4y ago
  Rust doesn’t have initializers in the C++ sense. And I mean, even in C++ many classes like shared_ptr or even lock_guard have constructors that don’t acquire the resources yet. When the resource is acquired is an API design concern; the important part is where it’s released.
  • jolux 4y ago
    This sounds like an argument that C++ isn't RAII.
    • somedudetbh 4y ago
      C++ _isn't_ RAII. RAII is a design pattern you can apply, leveraging C++ language features, in C++ in certain cases to avoid a certain class of bugs.
      • jolux 4y ago
        Well sure but I would assume the pattern would be consistently implied in the standard library, no?
        • jeffbee 4y ago
          The standard library necessarily has broad coverage of many use cases. That's why not every constructor of lock_guard acquires the lock. It's a completely legitimate use case that your thread happens to have a lock and wishes to use the end of lifetime of a lock_guard to release it. It's the same reason that you can construct a unique_ptr from an object that was allocated with new instead of with make_unique. Also, it's perfectly analogous to Go's `defer mu.Unlock()`.
        • beaukin 4y ago
          I'm not an expert, but I would so no, it's not. The point of learning to implement with RAII, in the context of C++, is so that one will apply it to use C++ in a more resource safe way. It will help avoid the bugs that the language will inherently allow if the programmer is not being otherwise being careful.
• Matthias247 4y ago
  Yes. Eg if you look at Java try-with-resources there is an exact scope during which resources live and can be used. At the end of the scope the .close() method will be called. For C++ and Rust there might not be a well defined scope since objects can be „moved“. Eg a method constructing an object can return it to the caller without the destructor being called.
  • jolux 4y ago
    It's well-defined, it's just more flexible than Java. The difference is that returning a value moves it, and resources are owned by the creating scope by default. Java doesn't have the same concept of ownership, or rather, you can't move values in Java.
• remram 4y ago
  Python's with keyword maybe? You can do with lock: # lock is held # lock released with lock: # lock is held again Also Go's defer keyword, which is bound to the current function (defer until function returns).
  • jolux 4y ago
    Right, but those are opt-in features. In Python you can lock something and not release it by mistake. In Rust this pattern is enforced, the destructor will always release it at the end of the enclosing scope unless there is a panic or infinite loop. I think this is a substantive difference.
    • tazjin 4y ago
      It's not enforced in Rust, but it's automatic unless you actively prevent it from happening. So you could say it's an opt-out feature. std::mem::forget is considered safe, as explained in its docs: https://doc.rust-lang.org/std/mem/fn.forget.html https://doc.rust-lang.org/std/mem/fn.forget.html
      • jolux 4y ago
        Fair enough, yeah.
• light_hue_1 4y ago
  Plenty of languages don't have RAII have SBRM. Scope based resource management predates the idea of constructors by decades. It's common in Lisp and Scheme. Haskel doesn't have RAII, but scope-based resource management is critical. ``` (call-with-output-file some-file (lambda (out) (write 'hello out))) ```
• mhh__ 4y ago
  D has constructs: scope(exit) foo(); // Call foo at the end of the scope scope(success) foo(); //Call foo if all goes well scope(failure) foo(); //Call foo if the wings fall off the plane.