4 ms·
In the end of the article the author addresses some of the pitfalls of using weak pointers. You'll only shoot yourself in the foot if you don't fundamentally un
by SwiftyBug 2y ago
In the end of the article the author addresses some of the pitfalls of using weak pointers. You'll only shoot yourself in the foot if you don't fundamentally understand weak pointers and why you're using them in the first place.
- usrnm 2y ago"It's only a problem when programmers make mistakes". Gee, I wonder where I've heard it before
- sethops1 2y agoI lost track of the number of WeakReference bugs I've had to fix in a legacy Java codebase. Not looking forward to doing the same in Go.
- sapiogram 2y agoAs someone who has never used weak references in either language, what are the common pitfalls in practical usage?
- sethops1 2y agoThe most common is if you create a reference to a field of a struct that is itself weak. The GC will gc the struct and your var can go from non-nil to nil under the hood despite having zero concurrent code (that you wrote). The good news is the vast majority of code using Weak semantics is gratuitous - "clever" code that is actually broken premature optimization, and the fix is to just Don't Do That.
- masklinn 2y agoAFAIK the biggest issue is the nondeterminism ("inconsistency"), especially in languages which have a weaker type system and make upgrading easy (which is the case of both Go and Java) - you need to remember to check the result for nil/null, but the type system won't tell you - if you upgrade twice in a row, you can have both fail, both succeed, or the first one succeed and the second one fail It can also be tricky to use them as building blocks for weak collections, if you want to avoid unbounded growth.
- jbverschoor 2y agoWhy? You just have to understand how they work, and it’s not like they’re invisible.
- sethops1 2y agoYou could make the same argument about writing in C/C++ and managing memory. You just have to understand how it works, right?