So I used to agree with you, but I've done extensive performance critical C development at Facebook (memcached, a new thing we are about to talk about) and I have also done extensive performance critical c++11 development (our layer 7 load balancer for http) and I'd have to say that c++11 is the far superior option if you really, truly understand what the compiler is doing to your code (a huge caveat).

Unique_ptrs are a total game changer, and the ability to use closures and lambdas when you want to set a callback function instead of a function pointer with a context pointer you have to cast and decode is absolutely huge for readability. maybe we aren't getting every last bit of performance out of it that we could with C, but it works at our pretty ridiculous scale, so I think C might have been a premature optimization for us.

First you are saying c++11 is the far superior option (with that one caveat) and in the last sentence you imply that C would still be faster. Can you clarify? I'll add my opinion too: I think all the readability you can get out of c++, will be wasted in layers upon layers of object oriented design and C compiles much faster, so there is that.

C++11 is the superior option because it is easier to write correct code with it, plain and simple. And we aren't talking about orders of magnitude difference in throughput or latency, we're talking about a slight increase in CPU idle.

And layers upon layers of object oriented crap is also a problem in C (I've seen it). At the end of the day I've just been burned more by the complexities of building large things in C (particularly when people do reference counting in C) than I have been by the complexity of c++ in general.

"Unique_ptrs are a total game changer"

You meant that a linear type system is a total game changes. Unique_ptrs are an ugly hack to emulate a linear type system in an inadequate language.

> With C you can easily get better (that is, safer) than C++ native MM just building a reference counting system on top of your C "objects".

Why build your own when C++ has std::shared_ptr.

I was referring about how to do it with C.

Hi antirez

C doesn't have a destructor that gets called when something goes out of scope. That's taken advantage of in C++ (RAII) to implement various things (like scoped_ptr that helps avoid leaks).

Refcounting is also not perfect for every case.

But I like and prefer C. ;) Just pointing out one thing different in C++.

How is a C implementation of std::shared_ptr safer?

Does anyone know of large projects where C++ handles memory allocation failures gracefully? For services that need to stay up and never crash under memory pressure, I would think C is the way to go. It's too hard to reason about control flow with exceptions.

You don't have to use exceptions in C++. You can do stuff the same way as in C by checking the return pointer.

I've worked on C++ apps that had built-in garbage collection (basically asset (geometry) paging) for huge amounts of data that would allocate/free/page on demand based on what was going on.

Sure, but then you can't use the standard library or any other libraries. Even a single exception sneaking into the codebase breaks everything.

We did - loads of Qt and std:: stuff - admittedly we used a custom memory allocator for the std:: stuff, but it worked fine.

Too performance critical for a GC! Reference counted all the way.