Hacker News Reader

Comment by andi999 | Hacker News Reader

If msvc would support a more modern C, i predict a lot of people would use this instead of C++. (Thanks Herb)

C11 support is on the roadmap since a few weeks ago:

https://developercommunity.visualstudio.com/idea/387315/add-...

I hope this also means the MSVC team had a change of mind regarding this very unfortunate blog post which IMHO did more damage to C than anything else in the last 20 years:

https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...

Your first link: that would be great, but somehow I can only find a statement that a c11 complient preprocessor is in the roadmap. Can you point me to something specific?

I can't sorry, since I'm not part of the MSVC team. The news that the MSVC preprocessor is C11 compliant made the round long before this specific ticket got the "Roadmap" tag slapped on though (which was on 20-Jul-2020). I guess we need to wait for the first results to show up in MSVC or a statement from MS.

And rightfully so, C code has no place in modern secure computing besides UNIX kernel clones, and legacy code.

Security should be provided by a sandbox technology. Is it wise to implement the sandbox in C (or C++, because that really doesn't make a difference)? Probably not. For most other use cases it's fine to use "unsafe languages".

Sandoxes don't prevent security exploits due to internal memory corruption of the sandbox.

But bad actors won't use memory-safe languages either ;) The purpose of the sandbox is to keep the damage contained, no matter if this damage was intended or not.

The less memory unsafe languages get used the better, regardless of sandboxing.

Here C++ has an edge over C, because it offers the language features for memory safe array and string manipulation, and most C++ compilers do offer bounds checking support, enabled by default in debug mode, and selectively in release if one so wishes.

Ideally, Swift, Rust, Ada, .NET Native would have replaced all use cases, but we are far from that ideal, so 2nd best solution, C++ for the time being.

Note that Apple and Google also reduce to the minimum the usage of C, and equally advocate C++ instead, alongside their managed languages for their OSes.

So yeah, you get C11 in the box, pity that the OS APIs are a mix of C++ and their own languages.

C++ as OS APIs (which so far only Microsoft seems to do in their UWP wrapper APIs, which is a fairly exotic use case) can be dealt with the same way as Objective-C on macOS and iOS: put all the code which talks to OS APIs into separate C++ or Obj-C source files, and put that code behind a simple C-API.

It's also interesting to note that Microsoft is only using header-only C++ wrappers, under the hood it's all plain old C-APIs via COM (because it would be a bad idea to expose C++ APIs in system DLLs).

The usage rules for C++ in Google's Fuchsia are so limited [1] that it is essentially a "C with classes", and it also has the rule that all shared libraries must have C APIs. I really don't see the advantage of using C++ for the underlying implementation compared to plain C if C++ has to be stripped down that much, and the public APIs are C APIs anyway.

[1] https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/...

COM with C is just for masochists, and no UWP is not exotic, all new Windows APIs since Windows 8 are mostly UWP, with Win32 frozen in Windows XP, given that Vista basically rebooted Longhorn features as COM/.NET instead of pure .NET components.

Header only libraries are a stop-gap solution until modules are fully done, then good luck with those C bindings into .NET metadata used by UWP.

Regarding Android and Fuschia, C++ with classes is still better than plain old unsafe C and if you cannot see the safety that C++ brings into C, then one more reason why those companies are on the good path to remove C as an option.

Doesn't seem extremely limited at all:

- Exceptions, RTTI, thread_local, Statically constructed object all require runtime support and are problematic in a kernel so it is not surprising - Virtual inheritance: almost litterally nobody uses it. - initializer lists require static storage which is also problematic in a kernel - operator overloading and trailing return types are a stylistic choice, but at the end of the day they are a tiny bit of C++

Things that are allowed: actual OO classes inheritance (including multiple inheritance), virtual functions, RAII, templates (no restrictions at all), lambdas, all the recent goodies. I.e. all the things that make C++, well, C++.

So it is way less restricted than other guidelines I have seen for well known C++ projects.

There is one thing about Swift vs C++. Like C, Swift now has a stable ABI. C++ will never have a stable ABI. Better now to start abandoning C++ for better languages.

C never had a stable ABI to start with.

That is a misconception from developers that don't understand C ABI == OS ABI, on OSes that happen to be written in C.

There is no C ABI on IBM and Unisys mainframes, Android, ChromeOS, WebAssembly and plenty of other OSes written in other languages.

OS/2 SOM, Windows COM and UWP are ways to achieve a compromise regarding how to expose a C++ ABI in a language neutral way. And stuff like gRPC also allows for something similar with inProcess calls.

Many of those better languages depend on LLVM, so no C++ is not going nowhere for the foreseeable future.

Problem we had was language designers spent 15 years targeting the JVM for new languages. But now finally there are good native languages like Rust, Swift, Golang, etc. Next thing is to write full compilers in those languages and ditch C++ and LLVM.

Good luck getting Apple, Google, Microsoft, IBM, ARM, NVidia, Khronos, or industry standards like AUTOSAR to ditch C++.

In fact they seem more focused on bringing Rust like capabilities to C++ static analysers, than anything else.

JVM has always been native by the way, for those that bothered to get hold of commercial AOT compilers, like PTC, J/Rockit, Excelsior among many others.

on systems that use the Itanium ABI, the C++ ABI is as standard as the C one.

I abandoned Microsoft compilers a long time ago due to their lack of support for newer C standards. I know a lot of other people that did, too.

It may also have contributed to a lot of software developers moving to Linux, which has always had great C compilers.

Reply on news.ycombinator.com