3 ms·

Due to language limitations, a lot of C programmers make all their variables shared pointers, which means they don't have to figure out how to do value semantic

Due to language limitations, a lot of C programmers make all their variables shared pointers, which means they don't have to figure out how to do value semantics, moving and copying objects, especially in multithreaded environments. Interestingly, it seems Rust programmers do the same too, because otherwise programming in Rust is too hard.

jstimpfle 4y ago
> Due to language limitations, a lot of C programmers make all their variables shared pointers, which means they don't have to figure out how to do value semantics, I wouldn't approve. Make shared (i.e. ref-counted) pointers when actually needed. Writing C is best when not mimicking bigger languages (i.e. with GC), but when figuring out how a system can work optimally.
- mgaunard 4y ago
  You might not approve, but the reality is that most C code is built like that.
secondcoming 4y ago
I assume you mean C++ here? In any case, in my experience this bad practice comes from Java devs who’ve moved to C++.
- moloch-hai 4y ago
  Java Disease is its own topic. But most shared pointer ownership in C is wholly ad hoc, without even reference counting.
- mgaunard 4y ago
  No, I mean C. People don't do that in C++, since C++ provides ways to define value semantics (copy, move, assignment).
tialaramex 4y ago
Your theory is that Rust programmers "make all their variables shared pointers" ? Even if I generously assume you're thinking of C++ "shared pointers", and so you've concluded that Rust's Rc<T> (a reference counted T) is basically the same thing, I don't see where you'd come to the conclusion that Rust programmers do this for "all their variables" as this seems wildly unlikely.
- mgaunard 4y ago
  Just look at the code in cargo. (A)rc is all over the place. It's essentially a cop out to not have to think about ownership and lifetime, and not have to worry about the borrow checker. The fact that this is so pervasive throughout Rust code is for me a sign that Rust failed to deliver on its initial promise. The borrow checker was meant to be its main value added. But heh, people still find value added to Rust otherwise.
  - tialaramex 4y ago
    Hmm. So the code I happened to have open was Aria's "Cargo mommy" which has neither Arc nor Rc anywhere, but is only a toy. So I did go look at Cargo itself, but unlike you although I do see some use of Rc and fewer of Arc it was scarcely "all over the place" when I looked and in the cases I spent any time actually thinking about it's a shared value, so, yeah, that makes sense. I randomly looked at cargo/core/profiles.rs and cargo/core/registry.rs and cargo/core/compiler/compilation.rs without finding either Rc or Arc used in those files at all. Searching across the whole repository I found some places which do use Rc, and fewer using Arc (implying this data is shared between threads) -- but this doesn't really support your original claim does it?
    - mgaunard 4y ago
      I never meant cargo itself.
  - zozbot234 4y ago
    > It's essentially a cop out to not have to think about ownership and lifetime Not a cop out. Something very much like Rc<> is needed whenever an object's lifecycle might be independently extended by multiple referencing "owners", none of which is subsumed by the others. That's a matter of broad high-level design that can't generally be avoided, least of all in a multi-threaded context (as shown by the use of Arc<>).

jstimpfle 4y ago

> Due to language limitations, a lot of C programmers make all their variables shared pointers, which means they don't have to figure out how to do value semantics, I wouldn't approve. Make shared (i.e. ref-counted) pointers when actually needed. Writing C is best when not mimicking bigger languages (i.e. with GC), but when figuring out how a system can work optimally.

mgaunard 4y ago
You might not approve, but the reality is that most C code is built like that.

secondcoming 4y ago

I assume you mean C++ here? In any case, in my experience this bad practice comes from Java devs who’ve moved to C++.

moloch-hai 4y ago
Java Disease is its own topic. But most shared pointer ownership in C is wholly ad hoc, without even reference counting.
mgaunard 4y ago
No, I mean C. People don't do that in C++, since C++ provides ways to define value semantics (copy, move, assignment).

tialaramex 4y ago

Your theory is that Rust programmers "make all their variables shared pointers" ? Even if I generously assume you're thinking of C++ "shared pointers", and so you've concluded that Rust's Rc<T> (a reference counted T) is basically the same thing, I don't see where you'd come to the conclusion that Rust programmers do this for "all their variables" as this seems wildly unlikely.

mgaunard 4y ago
Just look at the code in cargo. (A)rc is all over the place. It's essentially a cop out to not have to think about ownership and lifetime, and not have to worry about the borrow checker. The fact that this is so pervasive throughout Rust code is for me a sign that Rust failed to deliver on its initial promise. The borrow checker was meant to be its main value added. But heh, people still find value added to Rust otherwise.
- tialaramex 4y ago
  Hmm. So the code I happened to have open was Aria's "Cargo mommy" which has neither Arc nor Rc anywhere, but is only a toy. So I did go look at Cargo itself, but unlike you although I do see some use of Rc and fewer of Arc it was scarcely "all over the place" when I looked and in the cases I spent any time actually thinking about it's a shared value, so, yeah, that makes sense. I randomly looked at cargo/core/profiles.rs and cargo/core/registry.rs and cargo/core/compiler/compilation.rs without finding either Rc or Arc used in those files at all. Searching across the whole repository I found some places which do use Rc, and fewer using Arc (implying this data is shared between threads) -- but this doesn't really support your original claim does it?
  - mgaunard 4y ago
    I never meant cargo itself.
- zozbot234 4y ago
  > It's essentially a cop out to not have to think about ownership and lifetime Not a cop out. Something very much like Rc<> is needed whenever an object's lifecycle might be independently extended by multiple referencing "owners", none of which is subsumed by the others. That's a matter of broad high-level design that can't generally be avoided, least of all in a multi-threaded context (as shown by the use of Arc<>).