[codeflo]

I agree that memory management can't be solved locally. The situation in C++, where every library or API you use has a different cleanup convention, that you need to carefully read about in the documentation to even properly review a pull request, is proof of that.

I disagree that this criticism applies to Rust. For 99% of the cases, the idiomatic combination of borrow checking, Box and Arc gets back to a unified, global, compiler-enforced convention. I agree that there's a non-trivial initial skill hurdle, one that I also struggled with, but you only have to climb that once. I don't see that there's a limit to program complexity with these mechanisms.

[meindnoch]

>The situation in C++, where every library or API you use has a different cleanup convention, that you need to carefully read about in the documentation to even properly review a pull request, is proof of that.

Lol wut. The C++ resource management paradigm is RAII. If you write a library that doesn't use RAII, it's a bad library. Not a fault of the language.

[moregrist]

There’s a lot of C++ code out there and a lot that interfaces with C.

RAII is one method of cleanup but it doesn’t work in all situations. One that comes to mind is detecting errors in cleanup and passing them to the caller.

So it’s not right to call every library that doesn’t use RAII “bad.” There are other constraints, as well. Part of the strength of C++ is to give you a choice of paradigms.

[codeflo]

You have two choices.

Either you write code with good performance, which means that functions do take references and pointers sometimes, in which case you do have all of the usual lifetime issues. This is the proper way to use C++, and it's perfectly workable, but it's by no means automatic. That's the reality that my comment was referencing.

Or you live in a fantasy land where RAII solves everything, which leads to code where everything is copied all the time. I've lived in a codebase like this. It's the mindset that famously caused Chrome to allocate 25K individual strings for every key press: https://groups.google.com/a/chromium.org/g/chromium-dev/c/EU...

[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...

[jeremyjh]

I agree that a lot of that happens in the real world. I disagree that RAII is not used in the real world. I worked on a very large codespace for ATM client software and we used it pervasively, and the only memory leak we had in my time there was in a third-party library which ... required the careful reading of documentation you mentioned.

[cma]

2014, isn't that pre-C++11 in Chromium?