Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How do I deal with memory leaks? (2022)

stroustrup.com

Post reply on HN
Print view View original

41–50 of 76 posts

Re: How do I deal with memory leaks? (2022)

#41

Post by jjmarr »

shmolyneaux wrote: post #25

I think more people need to see this. This is how the creator of C++ thinks we should be writing code. This is what he thinks code should look like. To split a string by whitespace we should use `while (cin >> s)`. We should have a `typedef` in the middle of functions. Iterations should use `.begin()` and `.end()` everywhere. There might even be a bug with a trailing "+" appearing in the output? Imagine if this was a…

> Imagine if this was a new language that the dev community was seeing for the first time. It's hard to imagine it gaining much traction.

But it's not a new language. It's backwards compatible with C.

So "iterators" behave the same as pointers, since that's how you'd iterate through an array. You can add and subtract, then pass them to other functions.

You can't just have a function that returns a vector of strings, because that function would do an allocation. When is it deallocated? Before unique_ptr (the guide was written before), it'd be the caller's responsibility to manually do so.

Meaning you have to assign the output of that function to a variable every single time and manually remember to deallocated it or you get a memory leak.

C avoids this with `strtok` by destructively modifying the string in place. This is arguably worse.

If you were designing a new, non-GC, language, you'd have good ownership semantics and not allow pointer arithmetic. That'd be Rust.

Re: How do I deal with memory leaks? (2022)

#42

Post by ahartmetz »

materielle wrote: post #36
shmolyneaux wrote: post #25

I think more people need to see this. This is how the creator of C++ thinks we should be writing code. This is what he thinks code should look like. To split a string by whitespace we should use `while (cin >> s)`. We should have a `typedef` in the middle of functions. Iterations should use `.begin()` and `.end()` everywhere. There might even be a bug with a trailing "+" appearing in the output? Imagine if this was a…

If you want a laugh, Google a tutorial for how to read a file. You should also know that all the tutorials are wrong, because they fail to handle at least one footgun or another. There is no “modern” alternative. If you read Reddit threads, C++ programmers actually believe that it’s a reasonable file reading API. Most companies that I’ve worked at have just implemented our own on top of the OS syscalls. Which is anno…

QFile is mostly fine (it's probably not the fastest, but not slow), and QString is pretty comfy for all kinds of string manipulation :)

Re: How do I deal with memory leaks? (2022)

#43

Post by usefulcat »

eska wrote: post #14

Strange to see std::sort(), auto_ptr and RAII on the same page, when that combination was always broken.

auto_ptr is not used in the example that uses sort(), so "on the same page" is doing a bit of lifting here.

He's using auto_ptr to demonstrate RAII, which is fine. I would assume that the use of auto_ptr indicates that the example was written some time ago.

Re: How do I deal with memory leaks? (2022)

#44

Post by tombert »

foobarian wrote: post #39
tombert wrote: post #23

Earlier quoted context omitted.

Me neither. I have some very smart friends who think it's the perfect language, but I kind of prefer almost every language that has come out after C++. I feel like the language adds some very strange semantics in some very strange places that can be hard to reason about until you've spent a lot of time with the language. This wouldn't necessarily be so bad if not for the fact that most people who write C++ have not s…

Would you say Rust is more complicated than C++, or just harder to write? I think that complication a la C++ where there are too many features for the language's own good is a different problem than being a clean language but with higher order features that require a bit more, I don't know, focus?

I think there are certainly different complications in Rust than C++. The RAII can be roughly the same in the naive sense, but there's having to worry about Send and Sync and Pin and fighting with the borrow checker and all that fun stuff.

Gauging how "complicated" a language is somewhat subjective, so it's kind of hard for me to give a straightforward answer. I think it's certainly easier to be (some definition of) productive with C++ than with Rust. I feel like to do anything even remotely non-trivial with Rust, you kind of have to understand everything, because if you don't do it in the "Rust way", it often won't compile. I think this is a good thing, but it does make it harder to get started.

C++ has a lot less consistency and (kind of) more features, and lots of strange semantics to go with those features, and so if people actually use them it can get confusing and hard to read pretty quickly.

My knowledge is a bit out of date, to be clear; previously whenever I need something in the C++ domain, I could fairly easily just reach for C and use that instead. Now Rust is available and I think overall better (though I do sometimes miss how utterly simple and dumb C is).

Re: How do I deal with memory leaks? (2022)

#45

Post by my-next-account »

eska wrote: post #33
Panzerschrek wrote: post #26

Earlier quoted context omitted.

Use-after-free bugs are still possible, if an allocated memory chunk outlives the arena instance used for it. With C++-style owning containers such kind of errors is possible too, but it's not so frequent. But arenas can't be used in any case. They are suitable only if large amounts of allocations take place once and need to be deallocated all at once. If reallocation of freeing of individual memory chunks is needed,…

All of this is false. 1) An allocated memory chunk cannot outlive its arena (leaks are impossible). You probably mean a stale reference? The arena is put at such a level in the memory hierarchy that this bug becomes impossible. The bug here would be that the allocation was done in the wrong arena. In C this would be avoided by putting temporary arenas in a local function scope by passing them as parameters. Fool proo…

1) In practice, this is not true, especially if you implement unwinding in your arena.

You probably don't want to have an Arena in main, and you do all of your allocations from there, for example. That "just" leaks everything.

Here's a classic Arena-with-rewind bug:

  {
    Arena a;
    avec v(a);
    {
      RewindMark rm(a);
      v.push(1); v.push(1); // Trigger resize
    }
    v[2] // Oh no! The underlying data array has been deallocated
  }

Re: How do I deal with memory leaks? (2022)

#46

Post by kstrauser »

foobarian wrote: post #39
tombert wrote: post #23

Earlier quoted context omitted.

Me neither. I have some very smart friends who think it's the perfect language, but I kind of prefer almost every language that has come out after C++. I feel like the language adds some very strange semantics in some very strange places that can be hard to reason about until you've spent a lot of time with the language. This wouldn't necessarily be so bad if not for the fact that most people who write C++ have not s…

Would you say Rust is more complicated than C++, or just harder to write? I think that complication a la C++ where there are too many features for the language's own good is a different problem than being a clean language but with higher order features that require a bit more, I don't know, focus?

I make a strong distinction between complexity, the inherent amount of moving parts in a thing, versus complication, the amount of frippery involved in dealing with the complexity.

Rust is complex. It's solving complex problems. It's not complicated, though. There's not much you could remove without creating leaky abstractions.

In my opinion, C++ is equally complex. It's solving the same kinds of problems as Rust (although it'd be fairer to say "Rust is solving the same problems as C++"). However, it's hella complicated. There's a vast number of twists and turns to keep in mind if you want to use it, and most of them are things you could not have anticipated by reasoning about it from first principles.

If you took the design goals of Rust, and reinvented it from scratch, it'd probably end up looking a lot like Rust. If you were to reinvent C++ from scratch, I bet it wouldn't remotely resemble modern C++. If anything, I bet it would also end up looking like Rust, and the fractal of powerful footguns would be left on the cutting room floor because "that's insane, there's no way anyone would want that".

Re: How do I deal with memory leaks? (2022)

#47

Post by olivia-banks »

tialaramex wrote: post #7

> Modified February 26, 2022 So while a much older date is probably appropriate, maybe 20-30 years ago, we can at least mark this (2022) until somebody justifies a particular previous date.

It at least predates 2012, since the same text is seen on the this page's first archive on archive.org.

Re: How do I deal with memory leaks? (2022)

#48

Post by sufficientsoup »

tombert wrote: post #34
eska wrote: post #29

Earlier quoted context omitted.

Sounds like you would appreciate this talk: https://m.youtube.com/watch?v=wo84LFzx5nI&pp=ygUSVGhlIGJpZyB... Personally I use C or something, anything other than C++ really, if I need something more ergonomic or provably correct. Many excuse C++’s design history with “they didn’t know better”, but the oft forgotten history explained in that video shows otherwise.

I haven't played with Zig yet, but it does look like what I want C++ to be; something unapologetically low level but given some high-level constructs for safety and ergonomics. I haven't had a huge impetus to learn it because Rust has been happily occupying that space for me but it certainly can't hurt to play with Zig. I should write an Ffmpeg codec with it or something this weekend to try it out.

I've been having fun trying out Zig recently; would recommend. FYI that they released a big batch of API changes in April (version 0.16.0) so be mindful of learning from old resources.

Re: How do I deal with memory leaks? (2022)

#49

Post by foobarian »

tombert wrote: post #44
foobarian wrote: post #39

Earlier quoted context omitted.

Would you say Rust is more complicated than C++, or just harder to write? I think that complication a la C++ where there are too many features for the language's own good is a different problem than being a clean language but with higher order features that require a bit more, I don't know, focus?

I think there are certainly different complications in Rust than C++. The RAII can be roughly the same in the naive sense, but there's having to worry about Send and Sync and Pin and fighting with the borrow checker and all that fun stuff. Gauging how "complicated" a language is somewhat subjective, so it's kind of hard for me to give a straightforward answer. I think it's certainly easier to be (some definition of)…

> have to understand everything, because if you don't do it in the "Rust way", it often won't compile

I confess I haven't dug into it much yet, but this reminds me of how Haskell was. By the time you got a program to compile your project was more or less done.

Re: How do I deal with memory leaks? (2022)

#50

Post by tardedmeme »

eska wrote: post #27
HeliumHydride wrote: post #24

Earlier quoted context omitted.

auto_ptr was effectively split into std::unique_ptr and std::shared_ptr. The problem was that before C++11, there wasn't a way to distinguish between copy assignment and move assignment.

Correct. But the C++ language is not a language in which one should just say “screw it” and overload the assignment operator of all things while breaking its contract. Stuff like this is why many purists argue that operator overloading shouldn’t be a thing, because it can lead to shenanigans like this.

On the contrary, C++ lets you try such things, discover that they don't work well, and then undo them.
Post reply on HN