[dataflow]

You're missing a bunch of very important stuff in that page you linked to. See what they listed as the culprits:

> strings being passed as char* (using c_str()) and then converted back to string

> Using a temporary set [...] only to call find on it to return true/false

> Not reserving space in a vector

c_str() isn't there for "good performance" to begin with; it's there for interfacing with C APIs. RAII or not, GC or not, you don't convert to/from C strings in C++ unless you have to.

The other stuff above have nothing to do with C++ or pointers, you'd get the same slowdowns in any language.

The language has come a long way since 2014. Notice what they said the solutions are:

> base::StringPiece [...]

a.k.a., C++17's std::string_view.

[codeflo]

I'm responding to a comment that claims all lifetime issues are solved by RAII.

My argument was that for efficient code, you need to pass references or pointers, which means you do need to care about lifetimes.

And your argument is that's not true because we now have std::string_view? You do realize that it's just a pointer and a length, right? And that this means you need to consider how long the string_view is valid etc., just as carefully as you would for any other pointer?

[dataflow]

> I'm responding to a comment that claims all lifetime issues are solved by RAII.

I don't see anybody claiming this. The parent I see you initially replied to said "the C++ resource management paradigm is RAII", not "all lifetime issues are solved by RAII".

> My argument was that for efficient code, you need to pass references or pointers, which means you do need to care about lifetimes.

Of course you do. Nobody claimed you don't need to care about lifetimes. (Even in a GC'd language you still need to worry about not keeping objects alive for too long. See [1] for an example. It's just not a memory safety issue, is all.) The question was whether "every library or API you use" needs to have "a different cleanup convention" for performance reasons as you claimed, for which you cited the Chromium std::string incident as an example. What I was trying to point out was:

> that's not true because we now have std::string_view? You do realize that it's just a pointer and a length, right?

...because it's not merely a pointer and a length. It's both of those bundled into a single object (making it possible to drop them in place of a std::string much more easily), and a bunch of handy methods that obviate the ergonomic motivations for converting them back into std::string objects, hence preventing these issues. (Again, notice this isn't just me claiming this. The very link you yourself pointed to was pointing to StringPiece as the solution, not as the problem.)

So what you have left is just 0 conventions for cleanup, 1 convention for passing read-only views (string_view), 1 convention for passing read-write views (span), and 1 convention for passing ownership (the container). No need to deal with the myriads of old C-style conventions like "don't forget to call free()", "keep calling with a larger buffer", "free this with delete[]", or whatever was there over a decade ago.

> And that this means you need to consider how long the string_view is valid etc., just as carefully as you would for any other pointer?

Again, nobody claimed you don't have to worry about lifetimes.

[1] https://nolanlawson.com/2020/02/19/fixing-memory-leaks-in-we...