Only when there isn't a C++ compiler around, even if we restrict ourselves to the common subset, C++ has stronger type safety, while constexpr + templates are way better than macros.

Yeah, but if C++ is an option you can just as well skip over all the way to Rust, which is a better C++.

Except the small detail of missing tooling and ecosystem.

There are lots of scenarios where C++ is the only available alternative to C, with similar tooling level and libraries.

I lol every-time someone quotes their favorite JIT language that is essentially a meta-circular compiler for C library bindings.

“It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.” ( Albert Einstein )

Unfortunately we cannot get rid of the underlying OS ABI unless targeting bare metal.

The use cases where C is the best option are probably limited to exotic platforms that don't have compilers for better languages. There aren't many targets were you can't at least use C++.

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.

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)

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)

C still fills a niche nothing else really does in terms of being a lingua franca everyone can read that any language can talk to. The language is stable enough that code written today will probably have the same semantics far into the future, something C++ has been a lot more shaky about historically.