<p>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.</p>
<p>One approach, taken by C++ and Objective C, is to make the new language itself a superset of C.</p>
<p>Other languages do not have C <em>syntax</em> 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 <a href="https://learn.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke" rel="nofollow noreferrer">P/Invoke</a>.</p>
<p>What are the advantages and disadvantages of each approach?</p>

<language-design><c>
C source compatibility versus C linker compatibility
CC BY-SA 4.0
2023-07-03T18:46:35.167Z
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.
user
CC BY-SA 4.0
2023-07-03T18:50:03.457Z
@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.
dan04
CC BY-SA 4.0
2023-07-03T19:00:40.847Z
`sizeof 'a'` and `auto x = 0.5;` also have different behavior in C vs C++.
Bbrk24
CC BY-SA 4.0
2023-07-03T19:17:23.587Z
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)...
ghellquist
CC BY-SA 4.0
2023-07-03T20:48:55.193Z
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.
Eldritch Conundrum
<h1>PRO of Objective C Method - Easier To Intergrate And Use</h1>
<p>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.</p>

CC BY-SA 4.0
2023-07-03T23:51:53.077Z
2023-07-03T23:51:53.077Z
Starship
<p>The approach I would advocate would be to favor two goals:</p>
<ol>
<li><p>Maximize the range of constructs that could be accomplished via code that runs in both languages interchangeably.</p>
</li>
<li><p>Minimize the range of constructs that would be valid in both languages, but <em>with different meanings</em>.  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.</p>
</li>
</ol>
<p>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.</p>

CC BY-SA 4.0
2023-10-05T15:54:49.330Z
2023-10-05T15:54:49.330Z
supercat
<p>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 <em>extend</em> C while still providing memory safety, for instance -- that would involve major changes to idiomatic C code.</p>
<p>C++ and Objective-C both extend C in ways incompatible with C itself. C++ changes the default type of character literals from <code>int</code> to <code>char</code>, for example, and completely changes the meaning of <code>auto</code>. Objective-C eliminates the rule that <code>[[</code> must start an attribute -- consider the ubiquitous <code>[[NSObject alloc] init]</code>. 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.</p>
<p>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.</p>
<p>A drawback to allowing C interop means you have to <em>support</em> C's idioms, even if you don't <em>encourage</em> 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. <a href="https://developer.apple.com/documentation/swift/unsafepointer" rel="nofollow noreferrer">Swift</a> <a href="https://developer.apple.com/documentation/swift/opaquepointer" rel="nofollow noreferrer">has</a> <a href="https://developer.apple.com/documentation/swift/unsafemutablepointer" rel="nofollow noreferrer">no</a> <a href="https://developer.apple.com/documentation/swift/unsaferawpointer" rel="nofollow noreferrer">shortage</a> <a href="https://developer.apple.com/documentation/swift/unsafebufferpointer" rel="nofollow noreferrer">of</a> <a href="https://developer.apple.com/documentation/swift/unsaferawbufferpointer" rel="nofollow noreferrer">pointer</a> <a href="https://developer.apple.com/documentation/swift/unsafemutablerawpointer" rel="nofollow noreferrer">types</a> (<a href="https://developer.apple.com/documentation/swift/unsafemutablebufferpointer" rel="nofollow noreferrer">and</a> <a href="https://developer.apple.com/documentation/swift/unsafemutablerawbufferpointer" rel="nofollow noreferrer">three</a> <a href="https://developer.apple.com/documentation/swift/cvalistpointer" rel="nofollow noreferrer">more</a>), 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# <code>void*</code> is an exception to &quot;everything is an <code>object</code>&quot;, and Swift's pointers provide a very easy way to violate memory safety.</p>

CC BY-SA 4.0
2023-07-03T19:47:27.323Z
2023-10-05T02:37:59.690Z
2023-10-05T02:37:59.690Z
Bbrk24
# C source compatibility versus C linker compatibility
Posted by: username_0 on 2023-07-03
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](https://learn.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke).

What are the advantages and disadvantages of each approach?
**Tags:** language-design c
> **Comments:**
> **username_1**: 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.  
> **username_0**: @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.  
> **username_2**: `sizeof 'a'` and `auto x = 0.5;` also have different behavior in C vs C++.  
> **username_3**: 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)...  
> **username_4**: 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.  
---
## 3 answers
### Answer by username_2 on 2023-07-03. Score: 3 | Accepted answer
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](https://developer.apple.com/documentation/swift/unsafepointer) [has](https://developer.apple.com/documentation/swift/opaquepointer) [no](https://developer.apple.com/documentation/swift/unsafemutablepointer) [shortage](https://developer.apple.com/documentation/swift/unsaferawpointer) [of](https://developer.apple.com/documentation/swift/unsafebufferpointer) [pointer](https://developer.apple.com/documentation/swift/unsaferawbufferpointer) [types](https://developer.apple.com/documentation/swift/unsafemutablerawpointer) ([and](https://developer.apple.com/documentation/swift/unsafemutablebufferpointer) [three](https://developer.apple.com/documentation/swift/unsafemutablerawbufferpointer) [more](https://developer.apple.com/documentation/swift/cvalistpointer)), 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.
---
### Answer by username_5 on 2023-07-03. Score: 1
# 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.
---
### Answer by username_6 on 2023-10-05. Score: 0
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.
---
