Hacker News Reader

Comment by torstenvl | Hacker News Reader

Your comment seems to assume C++ is a better, safer language than C. I know a number of people who would sharply question that assumption.

I for one really hate destructors. They mean you can never tell what `delete` does. I remember a nasty double-free bug I had because of that.

View on HN

Well I guess it's a good thing no one ever had a double free in C :)

> They mean you can never tell what `delete` does.

Can you elaborate on this? A destructor is a function that's built into an object. It's really not more complicated than that. If malloc/free are functions that should be used in pairs, then the constructor/destructor pair tries to provide a convenient and structured way to know where malloc/free go. You would call new in the constructor and delete in the destructor.

I'm curious to know what you prefer?

Cases can arise where ownership of objects are not clear (which is a separate issue) but when they do occur, you can have a custom destructor that frees a lot of other objects, and then these other objects may in fact be "owned" elsewhere.

Somewhere down the line these other objects are freed again, causing double free.

How would malloc/free be better in that situation?

I don't know, but when I use C, I like to statically allocate everything if at all possible, I don't free() anything, I let the OS clean everything up at exit(). A lot of the small Unix utilities don't necessarily need dynamic memory allocation IMO

That's a good strategy in C++ too. Check the MISRA guidelines for example.

I'm not saying it's better, it wouldn't. Parent was asking in what scenarios can custom destructor causes issue so I just provided one.

malloc/free are better because free(window) could never call free(window->widget->font)

This sounds much more like a case of awful design than destructors being problematic

Can't argue with that.

First off, new/delete are only used for objects that are allocated on the heap. Even then, modern C++ has RAII wrappers such as std::unique-ptr. You should only need new/delete in rare cases.

This. Over the last few years of writing C++ on a daily basis, I can count the number of times I used `delete` on both hands (maybe one hand actually). `new` was harder to get rid of because of some flaw in the framework we used, but that has been fixed now. Unless you are in the business of writing smart pointers yourself, you should never have to use those keywords anymore.

By default, unique_ptr calls delete.

It therefore still calls the destructor.

So this has literally no bearing on the problem. It doesn't help at all.

Of course it calls the destructor. What else should it do? The point is that you don't get any double frees, because you never have to call delete manually. Or maybe I misunderstood your complaint?

Congrats on providing yet another reason why software should be at least open source (if not actually libre)

Reply on news.ycombinator.com