5 ms·
I'm not the person you are replying to but I would never use a non atomic refcounted smart pointer in C++ because the risks associated with it are just too high
by the_mitsuhiko 9y ago
I'm not the person you are replying to but I would never use a non atomic refcounted smart pointer in C++ because the risks associated with it are just too high. In Rust however the compiler protects me from misuse.
Separately emotionally I feel different about Arc<T> because all the counting is explicit and I see it. Understanding where shared_ptr<T> in C++ counts however can be quite a challenge, even if you consider yourself proficient with C++.
- gmueckl 9y agoI may be in the minority here, but if you are programming properly, your understanding of the code should always be good enough that this is a non-issue. If you manage to trigger a compiler error like this at all, you are most likely hacking, not developing.
- pcwalton 9y agoReference count problems routinely result in vulnerabilities. Google for [cve reference count].
- gmueckl 9y agoBut these vulnerabilities can only happen if reference counting is not automatic, right?
- pcwalton 9y agoNo, because of the way references in C++ work—you can take a reference to the inside of a reference counted object without manipulating the reference count. They could also happen if you used non-thread-safe reference counting on a thread-safe object. Now this seems to be rare in practice, because non-thread-safe reference counting is unusual. If it became more prevalent, however, I could see it happening.
- the_mitsuhiko 9y agoShould probably but I'm not a good enough developer (yet?) to guarantee that. I rather take the extra safety from the compiler.
- empath75 9y agoReal programmers apparently never make mistakes.
- moosingin3space 9y agoUnofficial slogan of the C apologism task force, apparently.
- gmueckl 9y agoNo. Real developers design their data structures and algorithms carefully. When it is tine to implement them, everything should be laid out clearly enough. There are industries where this kind of process is required and it truely shows in the quality of the results.
- kbenson 9y agoIf the vast majority of software is not made by real developers (and I think by the definitions you are espousing it is not), then I think one of the definitions is in need to change. As beneficial to your argument as it would be for that change to be the definition of "software", I don't think that's likely.
- gmueckl 9y agoI needed to make a distinction in the dedinition I gave. And I stand by it, even if the wording comes across as snarky. There are software engineering methods that are proven to work. They do not involve just diving in and changing the code. But I also think that there are valid reasons to not apply these rigid development practices to certain kinds of projects. For the rest, we might well get mandatory development standards forced on us to I am well aware of the pressure on developers to get requested feature done quickly. But the vast majority of bugs that get shipped would be easily prevented by more thorough processes. All those projects writing highly reliable software demonstrate this. But the price tag has a few zeroes appended as a result.
- 9y ago
- oconnor663 9y agoThis sort of mistake gets harder and harder to prevent as programs get larger. For example, one programmer might use a non-atomic Rc pointer to hold a string in some random Error value. Later, another programmer might try to parallelize that part of the program, without realizing that sending an Error across a thread boundary is now illegal. Or maybe the same mistake happens in the other order. Here's Niko Mastakis talking about a case where that happened to him (I think): https://youtu.be/lO1z-7cuRYI?t=4m https://youtu.be/lO1z-7cuRYI?t=4m
- swsieber 9y agoI don't trust myself to not make mistakes though even when I have a thorough understanding of what I'm making. "... trusting the programmer is fundamentally wrong, no matter the programming language"