Managed C++ has been replaced by C++/CLI in 2005 and it pretty much alive.

Its purpose was to make .NET interop easier with C++ libraries and has been quite successful at it, instead of having to play around with P/Invoke until everything works properly.

Regarding Windows, Microsoft is pretty much on the ongoing transition to C++, where these kind of issues are easier to tackle.

I bet their goals regarding Checked C have more to do with the adoption of UNIX (Linux/BSD) based technologies for Azure deployments and IoT devices like Azure Sphere.

There has been dozens of "safe" additions, variants and extensions to C along the years (from commercial companies, from individuals, from university labs, ...). Not one of them ever took off. This one did not either.

We always just say "hmmm... right... this one may look a bit better than the previous one (or doesn't)" and we never bother to use them. After 20 years like this, we can conclude that we like C as it is and are not interested in extra layers.

> After 20 years like this, we can conclude that we like C as it is and are not interested in extra layers.

This says a lot about how little the industry cares about software quality. You'd think a bunch of people who make a living out of automating tasks would happily use tools that automate the checking of an importnt source of bugs. Instead, many prefer to use tools that look simpler on the surface and then end up manually testing for the same kind of bugs over and over. So you have people writing in dynamically typed languages who rely on (manually written!) unit tests to check that their program is not mixing up types, and others using unsafe languages and then relying on tests to catch memory access violations. Inevitably, tests never catch all issues and you end up with type errors and segfaults in production.

> This says a lot about how little the industry cares about software quality. You'd think a bunch of people who make a living out of automating tasks would happily use tools that automate the checking of an importnt source of bugs. Instead, many prefer to use tools that look simpler on the surface and then end up manually testing for the same kind of bugs over and over. So you have people writing in dynamically typed languages who rely on (manually written!) unit tests to check that their program is not mixing up types, and others using unsafe languages and then relying on tests to catch memory access violations.

In the case of a "safer C" I suspect it's largely because it never materialized. C still has its deficiencies relative to Rust, but Rust is the first viable competitor.

Sure it did, all major systems languages outside UNIX universe were safer than C.

But the OSes they were tied to were killed by UNIX's adoption, just like the browser has helped JavaScript to take over areas of other languages.

For starters people have to realize that safe C is not a research problem. It's an engineering problem of compilers, package management and C software. And all it takes to take off is some engineering work.

However funding that work is a big problem, since it mostly benefits others.

You missed the most important one, people.

Mentalities are very hard to change and we all know that only lousy programmers make errors in C.

As far as I know, Managed C++ is mostly used as an interop layer between C/C++ and C#, sort of like the inverse of P/Invoke.

Since P/Invoke can't marshal C++ classes, Managed C++ gives you a way to expose such things. It's a very special-purpose chimera.