Hacker News Reader

Comment by Kranar | Hacker News Reader

Because for many of the use cases where C is used, switching to C++ involves jumping through even more hoops.

Do you have a couple of real world examples?

Embedded systems, for example.

I know it used to be, but is it really still common for embedded systems to use weird architectures that G++/Clang don't support?

Unless it is a popular system or common architecture, yes.

Could you show me an example of a micro controller still supported today which doesn't have a C++ compiler?

The 8051. I think C++ compilers technically exist for it, but for most hardware the only practical choice is the Keil C51 compiler, which is C89.

> is it common for weird architectures to exist?

> yes, unless you're using a common one.

That isn’t a contradiction.

Only very weird ones that barely support C like PIC, most ones support at least C++98 or C++11.

Any established C codebase, for example the kernel or Postgres?

Traditionally microcontroller firmwares as well, though those are increasingly friendly to C++, you just have to be careful about allocations as C++ makes it way easier to accidentally allocate than C does.

I'm not sure about other compilers, but compiling C code as C++ with MSVC ends up with pretty much the exact same code, instruction by instruction. C++ is a bit more strict though especially with casting, so a lot of code won't compile out of the box.

C++ code compiles to a different function names in object file (name mangling). You probably need to put a lot of ugly `#ifdef __cplusplus extern "C" {` boilerplate in your headers, otherwise C and C++ files will not compile together.

Don't forget the infamous pattern used in some C projects too:

  struct foo decl = {
    .member = /* ... */
    .next = &(struct nested_pointer) {
        .nested_member = /* ... */,
    },
    .array = (struct nested_array[]) {
      [0] = { /* ... */ },
    }
  };

This pattern does not work in C++ as the nested declarations become temporaries.

Nothing is stopping you from linking C++ code to Postgres.

But if you want to _contribute_ to PostgreSQL, it has to be in C.

> Any established C codebase, for example the kernel or Postgres?

Obviously you mean the Linux kernel, specifically. Also C++ has gotten a lot better since 2003 and before.

Examples of C++ usage in commercial codebases:

- anything Nintendo has written since 2010 (including microkernel, entire OS and all, for 3DS and Switch 1/2)

- well-known, high performing databases like ScyllaDB

> you just have to be careful about allocations as C++ makes it way easier to accidentally allocate than C does.

With the exception of exceptions (and coroutines but that's easily customizable), it's merely a standard library thing and doesn't affect language features (incl. language features exposed as std:: funcs/traits)

C++ has got a bad rep because it never fixes broken stdlib parts due to API and ABI concerns, and has many footguns due to this, that might make Rust and C better choices in corporate environments. However, IMHO, C++ is a much better language than C for personal projects, or when having a team of experienced folks.

> Any established C codebase

Anecdotally, GCC and GDB successfully (and incrementally) switched to C++ form C in the recent past.

The Linux kernel will never do it for ideological reasons of course.

I don't know about Postgres.

> > Any established C codebase, for example the kernel or Postgres?

> Obviously you mean the Linux kernel, specifically.

Or any BSD, or Illumos, or Solaris, or any Unix-derived kernel, or... Even the Windows kernel is in C (or a very cut-down C++).

Writing extensions for projects that support C extensions but may not support C++ extensions, e.g. many dynamic languages.

You can still write the extension in C++ and expose an extern "C" interface.

That's possible, but then the people building your extension need a C++ toolchain.

The question was "please provide examples where switching to C++ involves jumping through even more hoops", and in my view requiring downstream to use a C++ environment when they're expecting to use a C environment qualifies.

True. For me, C++ itself is the maze of hoops I would rather want to avoid.

Most C compilers are C++ toolchain as well, we are no longer in the 1990's.

Unless of course the project is using such a old compiler.

Problems in this domain arise more because you’re wandering off the beaten path for configuration and tooling than because the systems lack absolute capabilities. If you don’t want to build your extension the way that the extension framework expects you, all sorts of annoyances show up. Maintaining an cross-platform compatible C extension is hard enough already.

literally a good majority of existing embedded software coupled to applications in safety -- devices used by fire safety and first responders.

Reply on news.ycombinator.com