|
|
|
|
|
|
by questioner8216
204 days ago
|
|
|
It seems completely clear. He first gives unidiomatic C++ code, then next gives idiomatic Rust code, and differentiates the two based on the code snippets. It is a mistake on his part, and I do not see how it could reasonably be viewed otherwise. It is not a huge mistake, but it is still a clear mistake. |
|
|
From my reading, the section (and the article in general, really) is specifically focusing on mutexes, so the observations the article makes are indeed accurate in that respect (i.e., C++'s std::mutex indeed does not have automatic unlocking; you need to use an external construct for that functionality). Now, if the article were talking about locking patterns more generally, I think your criticism would hold more weight, but I think the article is more narrowly focused than that.
For a bit of a more speculative read, I think it's not unreasonable to take the C++ code as a general demonstration of the mutex API "languages other than Rust" use rather than trying to be a more specific comparison of locking patterns in Rust and C++. Consider the preceding paragraph:
> In languages other than Rust, you typically declare a mutex separately from your data, then manually lock it before entering the critical section and unlock it afterward. Here’s how it looks in C++:
I don't think it's unreasonable to read the "it" in the final sentence as "that pattern"; i.e., "Here's what that pattern looks like when written in C++". The example code would be perfectly correct in that case - it shows a mutex declared separately from the data, and it shows that mutex being manually locked before entering the critical section and unlocked after.