2 ms·

When I see a raw pointer in C or C++ code I know automatically that gotchas are involved and I need to be extra careful. When I see std::string_view, nothing t

When I see a raw pointer in C or C++ code I know automatically that gotchas are involved and I need to be extra careful. When I see std::string_view, nothing tells me that this may lead to memory corruption because the underlying storage may go away at any time (and the compiler will happily let this happen). New C++ features simply should not create new memory corruption footguns in addition to the existing ones, embarrassments like iterator invalidation are already bad enough (and worse than typical C memory management issues, because in C such issues are usually 'in your face', while C++ hides them beneath layers upon layers of stdlib abstractions).

dataflow 4y ago
> When I see std::string_view, nothing tells me that this may lead to memory corruption because the underlying storage may go away at any time That's not true. The word "view" quite explicitly tells you that it's a view... into something else, whose existence is generally independent of you (just like in real life!). If anything, it's clearer than an asterisk. > (and the compiler will happily let this happen). Just like with pointers and iterators. There's no difference here. > When I see a raw pointer in C or C++ code I know automatically that gotchas are involved and I need to be extra careful. You "know" this for iterators too. There's no reason why you can't "know" it for views too. It's not like they're introducing a new ownership concept here - these are just bounded versions of iterators and pointers.