4 ms·
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 hat
by torstenvl 4y ago
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.
- PaulDavisThe1st 4y agoCongrats on providing yet another reason why software should be at least open source (if not actually libre)
- moshegramovsky 4y agoWell 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?
- stevenhuang 4y agoCases 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.
- adrianN 4y agoHow would malloc/free be better in that situation?
- ihatepython 4y agoI 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
- adrianN 4y agoThat's a good strategy in C++ too. Check the MISRA guidelines for example.
- stevenhuang 4y agoI'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.
- torstenvl 4y agomalloc/free are better because free(window) could never call free(window->widget->font)
- scaredginger 4y agoThis sounds much more like a case of awful design than destructors being problematic
- stevenhuang 4y agoCan't argue with that.
- spacechild1 4y agoFirst 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.
- nlehuen 4y agoThis. 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.
- deleted 4y ago[deleted]
- torstenvl 4y agoBy 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.
- spacechild1 4y agoOf 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?