www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Should C linkage (aka "extern (C)") be the default when using

reply rempas <rempas tutanota.com> writes:
Am I the only one that things this way? If I'm not wrong, other 
than some (mostly runtime) advantages that "betterC" offers, It 
is also necessary when someone wants to allow their library to 
generate binding for other languages.

So I would say that not having to type "extern(C):" in the top of 
every file, would be great. Another things we could have is a 
compiler switch to choose the default linkage we want. Unless 
this is possible and I just not know it...
Mar 05 2022
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 06/03/2022 12:23 AM, rempas wrote:

 Am I the only one that things this way? If I'm not wrong, other than 
 some (mostly runtime) advantages that "betterC" offers, It is also 
 necessary when someone wants to allow their library to generate binding 
 for other languages.


Its certainly a more unique way of thinking.

After all, why would you lose function overloading for no good reason?

Not to mention, now if you build your code as -betterC, but use it in a 
non-betterC program, boom linker errors due to mismatching mangling.
Mar 05 2022
next sibling parent reply meta <meta gmail.com> writes:
On Saturday, 5 March 2022 at 11:34:34 UTC, rikki cattermole wrote:

 On 06/03/2022 12:23 AM, rempas wrote:

 Am I the only one that things this way? If I'm not wrong, 
 other than some (mostly runtime) advantages that "betterC" 
 offers, It is also necessary when someone wants to allow their 
 library to generate binding for other languages.


 Its certainly a more unique way of thinking.

 After all, why would you lose function overloading for no good 
 reason?

 Not to mention, now if you build your code as -betterC, but use 
 it in a non-betterC program, boom linker errors due to 
 mismatching mangling.


I misread rikki's comment

Loosing function overloading is indeed problematic, so it's not a 
so good idea..
Mar 05 2022
parent rempas <rempas tutanota.com> writes:
On Saturday, 5 March 2022 at 12:34:20 UTC, meta wrote:

 I misread rikki's comment

 Loosing function overloading is indeed problematic, so it's not 
 a so good idea..


You will lose function overloading anyway if you want to export 
you binding to the "C" way of mangling symbols (which is not 
mangling them at all). So if you want to have your library used 
from other languages without any more effort, you won't use 
function overloading or templates anyway!

 From the other hand, you can use D linkage in these symbols and 
then create an "interface" (or have someone else do that for you, 
lol!) with C linkage symbols that will call the overloaded 
functions or the template symbols. This is how I would do it!

The problem to my original post is that like Rikki said, it would 
be hard to make "extern(C)" the default without also modifying 
the module system.
Mar 05 2022
prev sibling parent rempas <rempas tutanota.com> writes:
On Saturday, 5 March 2022 at 11:34:34 UTC, rikki cattermole wrote:

 Its certainly a more unique way of thinking.

 After all, why would you lose function overloading for no good 
 reason?

 Not to mention, now if you build your code as -betterC, but use 
 it in a non-betterC program, boom linker errors due to 
 mismatching mangling.


Well, actually I didn't thought about that. Yeah, we need a way 
to show the linkage in the module so the import system won't 
fail. In that case, we either forget what I said or we need to 
also implement something like "extern(C) import module_name".
Mar 05 2022
prev sibling next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 5 March 2022 at 11:23:05 UTC, rempas wrote:

 Am I the only one that things this way? If I'm not wrong, other 
 than some (mostly runtime) advantages that "betterC" offers


There's no benefit to using extern(C). Why would you want it?


 is also necessary when someone wants to allow their library to 
 generate binding for other languages.


This is the *only* reason to use it and this is the same with and 
without betterC.
Mar 05 2022
next sibling parent reply meta <meta gmail.com> writes:
On Saturday, 5 March 2022 at 11:52:04 UTC, Adam D Ruppe wrote:

 On Saturday, 5 March 2022 at 11:23:05 UTC, rempas wrote:

 Am I the only one that things this way? If I'm not wrong, 
 other than some (mostly runtime) advantages that "betterC" 
 offers


 There's no benefit to using extern(C). Why would you want it?


 is also necessary when someone wants to allow their library to 
 generate binding for other languages.


 This is the *only* reason to use it and this is the same with 
 and without betterC.



There is if you want your code to be used within a C project, or 

extent)

Better C is very valuable, Rust has to go throught a lot just to 
provide similar functionality we get here

https://dev.to/dandyvica/how-to-call-rust-functions-from-c-on-linux-h37


I agree with OP, extern C should be the default in betterC mode!
Mar 05 2022
parent Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 5 March 2022 at 12:32:46 UTC, meta wrote:

 There is if you want your code to be used within a C project


I said you use it for the bindings. You should only extern(C) the 
necessary interface, not the whole thing.

Even in C, the recommendation is to make things `static` since 
not everything should be extern(C) even there! lol


 Better C is very valuable, Rust has to go throught a lot just 
 to provide similar functionality we get here


betterC has nothing to do with C interop.
Mar 05 2022
prev sibling parent rempas <rempas tutanota.com> writes:
On Saturday, 5 March 2022 at 11:52:04 UTC, Adam D Ruppe wrote:

 There's no benefit to using extern(C). Why would you want it?


I said advantages (but should have said "benefits" instead as you 
do) of using "betterC", not "extern(C)".


 This is the *only* reason to use it and this is the same with 
 and without betterC.


Right, I just said that probably someone will use "extern(C)" if 
they also use "betterC".
Mar 05 2022
prev sibling parent reply max haughton <maxhaton gmail.com> writes:
On Saturday, 5 March 2022 at 11:23:05 UTC, rempas wrote:

 Am I the only one that things this way? If I'm not wrong, other 
 than some (mostly runtime) advantages that "betterC" offers, It 
 is also necessary when someone wants to allow their library to 
 generate binding for other languages.

 So I would say that not having to type "extern(C):" in the top 
 of every file, would be great. Another things we could have is 
 a compiler switch to choose the default linkage we want. Unless 
 this is possible and I just not know it...


Basically pointless. The linkage of internal symbols has almost 
no relevance to a projects usability from C. You'd also be 
throwing away anything that requires name mangling, for zero real 
benefit.

If you want to expose a symbol to C then use extern(C). This is 
not hard to do.
Mar 05 2022
parent reply rempas <rempas tutanota.com> writes:
On Saturday, 5 March 2022 at 17:09:22 UTC, max haughton wrote:

 Basically pointless. The linkage of internal symbols has almost 
 no relevance to a projects usability from C. You'd also be 
 throwing away anything that requires name mangling, for zero 
 real benefit.

 If you want to expose a symbol to C then use extern(C). This is 
 not hard to do.


Actually, we are saying the same thing. The only reason to use C 
linkage is to "expose" symbols (aka allowing it to call it with a 
known name) from C. This will allow your library to be used from 
C and from any language that can use C linkage.
Mar 05 2022
parent max haughton <maxhaton gmail.com> writes:
On Saturday, 5 March 2022 at 20:48:45 UTC, rempas wrote:

 On Saturday, 5 March 2022 at 17:09:22 UTC, max haughton wrote:

 Basically pointless. The linkage of internal symbols has 
 almost no relevance to a projects usability from C. You'd also 
 be throwing away anything that requires name mangling, for 
 zero real benefit.

 If you want to expose a symbol to C then use extern(C). This 
 is not hard to do.


 Actually, we are saying the same thing. The only reason to use 
 C linkage is to "expose" symbols (aka allowing it to call it 
 with a known name) from C. This will allow your library to be 
 used from C and from any language that can use C linkage.


Which is trivially done now, whereas making it the default with 
betterC means you lose a bunch of D features
Mar 05 2022