Who else finds it a bit annoying that C++ has such a bad reputation while C is still somehow seen as the holy grail of low level programming?

The online rhetoric around C++ is a little bit ridiculous. The common complaints seem to be the plethora of "foot guns", complete lack of memory safety, and needless complications. C, however, doesn't seem to get any heat. To the point where most "modern" languages model themselves around it (Zig and Go are examples of this). Go wouldn't need to be garbage collected if it was based on C++, since C++ can handle memory automatically. The only reason they chose GC for Go is because it's based on C. Same with Python.

I can't imagine any project based around or using C++ ever opting for GC because I think it would take effort to avoid objects automatically deallocating when they go out of scope. You'd have to put effort into caching memory and ensuring they live outside their natural lifetime just to pay the expense of deallocating chunks of useless memory at certain intervals.

The only possible way to base a language around C and abstract away the raw memory management is to wrap that memory management in objects. Without objects, it becomes mandatory to expose some kind of function call that the user must call to get rid of memory. But that's where GC comes in. GC is the solution to avoiding deallocation functions.

When it comes to C, the language is pretty dead simple. However, it becomes incredibly complicated the instant you need to actually do anything. Need to work with a string? Prepare to manually allocate/reallocate to do literally anything. As well as free it and ensure no double frees. Need an array? Again, prepare to malloc/realloc as well as be responsible for manually tracking the length. You can obviously put in helper functions for these things, but now you're adding complications to the interface since you need to be aware of all the possible wrapper functions for whatever type of data you're working with.

`itemA_dealloc(itemA *i);`, `itemB_dealloc(itemB *i);`, etc. No possible way to allow the items themselves to handle any and all deallocation. The consumer of your interface is entirely responsible for understanding not only the specific methods to call, but also be aware of the specific scope of all of these data types. Some items should be deallocated once they're used to allocate something else while other items might need to live for the same scope as whatever they were used to allocate. The order of deallocation is also important, which can make deallocation in C an incredibly complex procedure.

Also, as a personal nitpick, it's nearly impossible to browse your options in an IDE. With objects, you can literally just type `myItem.` and it'll list possible options. C doesn't give you that type of scope in your IDE which means you're far more likely to need to consult documentation outside of your editor.

C++ obviously solves these via OOP. std::vector, std::string, or any custom implementation can ensure proper, safe, and consistent memory management through standard OOP practices while also completely abstracting the internals away from the user. It becomes much easier and less complex for the user to work with your interface.

C++, at least since C++11 (which is pretty ancient by today's standards), also completely solves memory issues with smart pointers (even before this it's always been possible to implement smart pointers anyway). There's now no reason to be manually allocating on the heap instead of using shared_ptr or unique_ptr. In a concurrent environment, shared_ptr is a lifesaver. You can send a shared_ptr through an asynchronous pipeline and ensure that it'll stay in scope and be freed when no longer needed. To go even further, shard_ptr can be optimized by passing it by reference when you don't need to pay for the refcount. The complication of trying to ensure that multiple threads/async functions are perfectly managing the memory is eliminated. Memory safety is a long solved problem in C++, but it's not something that can be