In discussions about whether to cast the result of malloc or not when coding C, one common argument is that if you cast the result then you can compile your C code with a C++ compiler.

Why would one ever want to do that? If I'm not mistaken, there are C compilers available for almost any platform imaginable, but the opposite is not equally true.

So why do people want to compile their C code with a C++ compiler? Why not just use a C compiler instead? C is tricky enough as it is. Keeping track of all the details that would ensure that it's equivalent (nut just valid) C++ code can be quite tricky, especially since there are quite a lot small things that are valid in both languages, but mean different things. Furthermore, it also makes it impossible to use some of the nice new features in modern C.

So what is the use case of coding "C-style C++"?

  • 4
    Why do people eat chocolate ice cream instead of vanilla? The answer to that question is equally rational. Software developers also routinely ask the i++ + ++i question on Stack Overflow, even though it is pointless. Nobody knows where this question comes from, and it always leads nowhere ("nowhere" being defined as undefined behavior and "never write code like this"). Jul 5, 2020 at 23:24
  • @RobertHarvey Well, that's what I'm asking. Just because I cannot see any good use case does not make me assume that there is none.
    – klutt
    Jul 5, 2020 at 23:26
  • 2
    This is discussed at great detail in this Stack Overflow question. Jul 6, 2020 at 0:56
  • 6
    Well, you could be using a C library in a C++ program. Jul 6, 2020 at 2:42
  • 1
    It depend on project that developer working on. If they are working on a kernel, they do not have support for most of what C++ has.it looking like C. outside the kernel, the support for the rest of C++ is available - which can make applications easier to write.
    – AjayGohil
    Jul 17, 2020 at 6:10

6 Answers 6



Back in the day everyone was a C/Fortan/Lisp programmer - and when they moved to other languages complained about this feature, or that restriction. What you got were programs looking like C/Fortran/Lisp just not written in C/Fortan/Lisp.

Now days many C++/Java/Haskell/etc.. programmers now have to write C code. And complain about the this feature, or that restriction. What you get are programs looking like they were written in C++/Java/Haskell/etc... just not written in C++/Java/Haskell/etc...

Perhaps I'm already out of date on who the programmers are. I hear there is this upstart language called JavaScript. Wonder if anyone is going to start writing programs that way, that aren't written in JavaScript. Wait...

Same music different singers.


Turns out that writing a cast in front of a malloc lets you be very clear what the malloc is mallocing, even if the malloc is split from the variable declaration as I believe (at least historically so) C variables must be declared in advance of scoped operations, which isn't always where you want to perform allocations. Last time I checked casting a pointer is perfectly valid C.

My hunch is that people try to rationalise this by claiming interoperability (which it surely supports), but they are really trying to write code that is clear to the audience who is going to read it. Now days many C programmers are also C++ programmers, and C++ programmers are habit driven to specify type in an allocation (I'm looking at you new T()).


Lots of people use C++ as “better C”. And there’s nothing wrong with that. It’s something that’s still very easy to understand for someone who learned only C, and that is better than plain C.

So there’s nothing wrong with writing C code that compiles identical as C++ code.

  • 1
    How can it be "better than plain C" if you're not allowed to use any of the C++ specific features?
    – klutt
    Jul 6, 2020 at 12:23
  • 3
    @klutt. A stronger type system. For the same code, a C++ compiler is more likely to catch an error then a C compiler. Jul 6, 2020 at 12:35
  • @NemanjaTrifunovic Well, that's true, but then what's the reason of restricting yourself to make it compile as C? Why not just use C++?
    – klutt
    Jul 6, 2020 at 14:56
  • Because you want to use an incremental improvement to C, and not a whole new language with new idioms. We could call it C+1, or ++C, or ...
    – Useless
    Jul 6, 2020 at 15:04
  • 4
    Look up “pragmatic” in the dictionary. It’s a very important word. It’s the opposite of “dogma”.
    – gnasher729
    Jul 7, 2020 at 15:41

The one use case I consider halfway valid is that you are transitioning from C to C++, and you are temporarily using C-style memory management to minimize the amount of work; basically, a lift-and-shift operation.

Then, once you have it building and running as C++, you gradually change out the C-style memory management for the more robust C++ features.


Writing code which can be compiled with a C and C++ compiler as well simply extends the number of projects and cases where the code can be reused. You asked

Why not just use a C compiler instead?

Well, in several C++ projects people would be pretty hesitant to use two different compilers, since it would complicate their setup. Now imagine the case where a piece of code is used and maintained mainly in a C environment, but with the option of also reusing it in another project which works with C++. That would be a good match for writing C-style C++.

Sometimes, developers love to do such things "just in case", not knowing if there will be ever a C++ project where the code will be reused - and this is where things become questionable.

  • In the case of coding in the common subset of C (some version) and C++ (some version), one has to admit that the single valid reason for doing so for implementation files (compiling everything at once for whole-program-optimization) has been overtaken by implementation improvement (lto anyone?). Are you aware of any platform where you have a C++ compiler but not a C compiler, even if for an older version? Dec 18, 2021 at 13:43
  • @Deduplicator: In the embedded systems world, some code may need to be able to run on multiple platforms, some of which have reliable C++ compilers available and some of which do not.
    – supercat
    Aug 10, 2023 at 21:35
  • @supercat The point is that there is no platform having a good C++ but no C compiler. And calling C code is easy from both. Aug 10, 2023 at 23:10
  • @Deduplicator: I don't know of any C++ compilers for the PIC family; my biggest piece of dual-mode code was used to run as C++ on MSVC and as C code on the PIC. Also, while I've not tried linking clang/gcc-generated object files with e.g. Keil, processing everything wiht one compiler seems easier than using two. Yes, I know later versions of Keil presumably support later versions of C++, but I think that's only when using the clang-based versions which I don't view as trustworthy.
    – supercat
    Aug 11, 2023 at 15:40

Why are people coding “C-style C++”?

Historic inertia.

When C++ arrived, it was quite successful - a big hit. A lot of transitions of C code to C++ could be done with little re-work. Dual C/C++ development/maintenance was initially possible. C++ was looking to not be just another language, but a successor to C as ever increasing classes appeared.**

Importantly C itself was paused in it development to allow steady C to C++ transitions to continue and C++ to mature without playing catch-up with C.

But C did not get subsumed. C99 hit with VLA, FAM, long long, restrict, and hurt that compatibility model. C marched ahead with attributes not found in C++. C and C++ diverged significantly since then and with C11. C++ marched away too from C with template fever. The parent and child no longer live in the same house.

Yet for many, the model of transitional compatibility persisted. MS today only includes in their C89-ish C, C99/C11 features found in C++. My experience with professors on Stackoverflow see the educator community continue to push for a C using only common features. There is much inertia.

So what is the use case of coding "C-style C++"?

It is a use case that diminishes each year with major steps apart with each C release. IMO, since C11, it is just gone.

** Early C++ coding was a translator from C++ source to C source and then to a compiler. Thus anything done in C++ could be done in C - just a question of ease.


The main reason I can think of is other people.

There are a lot of C++ programmers out there. If your software ever might get touched by one of them, it makes their life easier if you use the common portions of the languages when possible.

There's also the case where you are compiling someone's library into your own program. Many times the build tools will handle the C vs. C++ differences correctly. Other times, it's a bit of a pain. Much easier if one uses the common portions of the languages.

And in the particular case of malloc, its more explicit to use the cast. Many programming style guides recommend explicitness when it comes to memory management because the cost of debugging a mistake in memory management is so brutal.

  • 2
    There is no type mentioned in p = malloc(n * sizeof *p);. How can you be more explicit than that without appreciably increasing the likelihood of bugs? Jul 7, 2020 at 20:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.