Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What should have been the term for RAII?

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 62 posts

Re: Ask HN: What should have been the term for RAII?

#21

Post by remram »

jolux wrote: post #6
jeffbee wrote: post #5

Earlier quoted context omitted.

RAII isn't just about automatic ("scope-based") variables. RAII refers to the way the language ties together the construction and allocation of the object.

Are there languages that do SBRM but not RAII?

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).

Re: Ask HN: What should have been the term for RAII?

#23

Post by jolux »

remram wrote: post #21
jolux wrote: post #6

Earlier quoted context omitted.

Are there languages that do SBRM but not RAII?

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).

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.

Re: Ask HN: What should have been the term for RAII?

#24

Post by jolux »

somedudetbh wrote: post #14
jolux wrote: post #11

Earlier quoted context omitted.

This sounds like an argument that C++ isn't RAII.

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.

Well sure but I would assume the pattern would be consistently implied in the standard library, no?

Re: Ask HN: What should have been the term for RAII?

#25

Post by jeffbee »

jolux wrote: post #24
somedudetbh wrote: post #14

Earlier quoted context omitted.

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.

Well sure but I would assume the pattern would be consistently implied in the standard library, no?

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()`.

Re: Ask HN: What should have been the term for RAII?

#27

Post by tazjin »

jolux wrote: post #23
remram wrote: post #21

Earlier quoted context omitted.

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).

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.

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

Re: Ask HN: What should have been the term for RAII?

#29

Post by jolux »

tazjin wrote: post #27
jolux wrote: post #23

Earlier quoted context omitted.

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.

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

Fair enough, yeah.
Post reply on HN