←back to thread

271 points mithcs | 1 comments | | HN request time: 0s | source
Show context
throwaway889900 ◴[] No.45955220[source]
Does the StringView/Span implementation here seem lacking? If the underlying data goes away, wouldn't the pointer now point to an invalid freed location, because it doesn't track the underlying data in any way?
replies(2): >>45959150 #>>45959788 #
loeg ◴[] No.45959150[source]
That's what std::string_view and std::span are, though. They're views / borrows over the underlying data, minus the kind of protections something like Rust has about lifetimes of the underlying data vs the borrow.

The benefit of these types is that they're a pair of pointer+size, instead of just a bare pointer without a known size.

replies(1): >>45959477 #
throwaway889900 ◴[] No.45959477[source]
True, I guess I was expecting if you were reimplementing these with additional protections, why not add the protection using the custom pointer reimplementations to ensure no use after frees. Seems like a missed opportunity.
replies(1): >>45959834 #
1. loeg ◴[] No.45959834[source]
I don’t think there is a way to do this generally without GC, and that leads to significant pitfalls anyway (eg in Java you can accidentally end up holding multi-GB strings in memory because a few references to short substrings exist).