undefined | Better HN

0 pointsmeindnoch2y ago0 comments

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

0 comments

moregrist2y ago

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.

codeflo2y ago

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

dataflow2y ago

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.

codeflo2y ago

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?

1 more reply

jeremyjh2y ago

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.

cma2y ago

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

j / k navigate · click thread line to collapse

0 comments

moregrist2y ago

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.

codeflo2y ago

You have two choices.

dataflow2y ago

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.

codeflo2y ago

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.

1 more reply

jeremyjh2y ago

cma2y ago

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

j / k navigate · click thread line to collapse