Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Why would you jump through all these hoops instead of just writing C++ if you want "C with generics"


because i work on a legacy project that is coupled to safety regulations and other quality guarantees, and we cannot just simply roll out a solution ported to c++ on the next release, or even tenth, so perhaps we make it work until we can.

however we can set a standard and expectation for new projects to use c++, and we do and set an expectation to target a specific std.

i see this sentiment quite a lot on hackernews -- feels like a lot of people saying "git gud" -- i would expect a lot more nuance applied here.


While using old compilers in certified domains is a common problem, unless we are talking about stuff like PIC, the choice of reaching out to C++ compilers is a given, even if what they might support is between C++98 and C++11.


Out of curiosity, what is an example of a regulation that specifies using a specific programming language and/or toolchain out there?


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?


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.


> 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++).


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


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


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.


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


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.


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.


Because some people really hate C++ to their bones, hence this kind of stuff that keeps coming up.

I was really disappointed that Microsoft decided to backtrack on C++'s is the future, after the new found Linux and FOSS love.

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

https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-...

Not that it matters much, as nowadays C and C++ have a new policy at Microsoft due to goverments and cyberlaws.

https://azure.microsoft.com/en-us/blog/microsoft-azure-secur...

https://blogs.windows.com/windowsexperience/2024/11/19/windo...


The real answer: it's more fun this way.


Why would you write C++ if you can get the same result by jumping through a few hoops with C?


Templates in C++ require language support - you can't simply implement them with "a few hoops" in C.


Templates are a solution for a problem that c++ themselves created


You mean the same problem that the article is trying to solve in C? Generic data structures?


What problem?




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: