Due to the large amount of existing code written in C, it's common for languages to provide some sort of mechanism for interoperating with C.

One approach, taken by C++ and Objective C, is to make the new language itself a superset of C.

Other languages do not have C syntax compatibility, but do allow calling into pre-compiled (static or dynamic) libraries written in C. For example, the .NET Framework allows calling “unmanaged” code with P/Invoke.

What are the advantages and disadvantages of each approach?

  • $\begingroup$ I heard somewhere (from Bbrk24?) that Objective-C started out as merely a C preprocessor. C++ isn't really a superset of C, but I assume it was designed to look similar to C mainly because of familiarity. $\endgroup$
    – user
    Jul 3, 2023 at 18:46
  • $\begingroup$ @user: Strictly speaking, C++ isn't a superset of C, because there are things you can do in C that you can't do in C++. Like implicitly convert a void* to another pointer type, or name a variable this. It's an "almost" superset, though. $\endgroup$
    – dan04
    Jul 3, 2023 at 18:50
  • $\begingroup$ sizeof 'a' and auto x = 0.5; also have different behavior in C vs C++. $\endgroup$
    – Bbrk24
    Jul 3, 2023 at 19:00
  • 2
    $\begingroup$ A slight bit of nitpicking here: most often interoperability seems to not be part of the language per se, but part of the compiler implementation on a specific architecture. As example I remember VAX VMS where just about any language could call on just about any other language (well, mostly)... $\endgroup$
    – ghellquist
    Jul 3, 2023 at 19:17
  • 2
    $\begingroup$ Making the new language itself a superset of C is a HUGE design constraint that will determine most of your language (not to mention it also continues to propagate well-known design mistakes from half a century ago). If the problem is having interop with C, it is simpler to solve just that problem directly. $\endgroup$ Jul 3, 2023 at 20:48

3 Answers 3


Extending C means you get most of a language for free. This can be good, sometimes, but it causes problems if the goals of your language run counter to what C allows. It's impossible to extend C while still providing memory safety, for instance -- that would involve major changes to idiomatic C code.

C++ and Objective-C both extend C in ways incompatible with C itself. C++ changes the default type of character literals from int to char, for example, and completely changes the meaning of auto. Objective-C eliminates the rule that [[ must start an attribute -- consider the ubiquitous [[NSObject alloc] init]. They also both add some keywords that restrict what identifiers are allowed in plain C code, though perhaps that's inevitable with an extension like those.

The vast majority of modern languages provide C interop rather than trying to look exactly like C. This allows changes to the syntax, ranging from removing semicolons to completely reinventing the macro system. Most popular languages still have somewhat C-like syntax, and the C family of programming languages is quite large, but mimicking C exactly is usually a non-goal for modern languages.

A drawback to allowing C interop means you have to support C's idioms, even if you don't encourage them: someone's going to need to call a function that uses pointers eventually, and you need to give them some way to do it. Swift has no shortage of pointer types (and three more), to be used in different situations. Some languages care less than others, though, and some require the glue code to live on the C side instead. Sometimes, giving a language access to pointers means breaking the promises you started with: for example, C# void* is an exception to "everything is an object", and Swift's pointers provide a very easy way to violate memory safety.


PRO of Objective C Method - Easier To Intergrate And Use

Developers directly incorporate existing C code their language projects giving easier integration of C code and access to many libraries and other functionalities. People that use C can easily transition since the syntax and semantics of C are the same and therefore reducing the learning curve and helps the learning of the language.


The approach I would advocate would be to favor two goals:

  1. Maximize the range of constructs that could be accomplished via code that runs in both languages interchangeably.

  2. Minimize the range of constructs that would be valid in both languages, but with different meanings. For purposes of this rule, it would not be objectionable for a construct to be categorized as Undefined Behavior if most C implementations can be configured to extend the semantics of the language to process it the same way as the new language.

As an additional goal, it should be possible for programs that operate interchangeably in both languages to supply the new-language compiler with information that it allow it to generate more efficient machine code than would be possible in C, thus providing an incentive for people to start writing code in the new language, but in such such a way as to still be compatible with existing C tools, and for people who could process code using the new language to do so rather than using the existing C compiler.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .