If you are happy with the cost of the indirect call, what stops you from creating this wrapper in a statically compiled language without GC on stack? I don't think these are related. The big issue *is* the indirect call, which can be prohibitively expensive.
-
-
Replying to @zeuxcg
If a subtyping relationship is implemented by a conversion like vector<t>(const vector<u>&) that works by holding a reference to its input, then the dangling reference issues will be explosive. This led C++ down the string_view path to distinguish epemeral things.
2 replies 0 retweets 3 likes -
Replying to @TimSweeneyEpic
It seems orthogonal to me. If you want a typed view into the original vector, you need the lifetime to match - but it doesn’t seem too different from passing a reference to a vector to some other system without any type conversions?
2 replies 0 retweets 3 likes -
Replying to @zeuxcg
What all of these subtyping-through-zero-copy-sharing-through-manual-memory-management solutions have in common is that, in a large program, the combinatorial complexity of all of these lifetime relationships is impossible for a human to comprehend. Thus libraries don't do it.
2 replies 0 retweets 6 likes -
Replying to @TimSweeneyEpic @zeuxcg
I agree. But you are suggesting to have the computer take care of the combinatorial complexity instead. That still doesn't solve the fundamental problem that it's still impossible for a human to comprehend.
1 reply 0 retweets 0 likes -
Resulting in programs that are technically correct, but run out of memory. Because the actual problem the user had was not memory management but ownership. Memory management is a symptom.
1 reply 0 retweets 0 likes -
To further illustrate my point, imagine a language that never releases memory ever. You can allocate and reference as much as you want. There is no free. The language is both technically correct, trivial to implement, doesn't have any GC/ref-count/RAII issues,
1 reply 0 retweets 1 like -
collection views are trivial, object lifetime is trivial. It's also blazingly fast. Everything is objectively better than any GC-based language or manual memory management language can ever be. The only problem would be running out of memory.
1 reply 0 retweets 2 likes -
As programs in any GC-based language grow, they resemble this "never free" model more and more, because none of the languages addressed the fundamental problem the user had in the first place.
1 reply 0 retweets 1 like -
Replying to @CodeLumpN @zeuxcg
Unwanted allocations can accumulate when live data reference them unintentionally. Memory waste is a lesser problem than dangling pointers to freed memory that lead to unreproducible bugs or security threats.
2 replies 0 retweets 1 like
Compare to the update regimen associated with web browser security flaws, compared to the lax attention paid to memory leaks.
-
-
Replying to @TimSweeneyEpic @zeuxcg
We can all agree that dangling pointers are the worst. Which is why languages like Rust and C# exist in the first place. We just disagree on which bullet to bite instead.
1 reply 0 retweets 0 likes -
For the type of software I'm concerned about, pre-allocating most data and stack allocating everything else is a good strategy.
1 reply 0 retweets 0 likes - 5 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.