digitalmars.D - Should C linkage (aka "extern (C)") be the default when using
- rempas (8/8) Mar 05 2022 Am I the only one that things this way? If I'm not wrong, other
- rikki cattermole (5/9) Mar 05 2022 Its certainly a more unique way of thinking.
- meta (4/15) Mar 05 2022 I misread rikki's comment
- rempas (13/16) Mar 05 2022 You will lose function overloading anyway if you want to export
- rempas (5/11) Mar 05 2022 Well, actually I didn't thought about that. Yeah, we need a way
- Adam D Ruppe (4/8) Mar 05 2022 This is the *only* reason to use it and this is the same with and
- meta (8/17) Mar 05 2022 There is if you want your code to be used within a C project, or
- Adam D Ruppe (6/9) Mar 05 2022 I said you use it for the bindings. You should only extern(C) the
- rempas (5/8) Mar 05 2022 I said advantages (but should have said "benefits" instead as you
- max haughton (7/15) Mar 05 2022 Basically pointless. The linkage of internal symbols has almost
- rempas (5/11) Mar 05 2022 Actually, we are saying the same thing. The only reason to use C
- max haughton (3/16) Mar 05 2022 Which is trivially done now, whereas making it the default with
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
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
On Saturday, 5 March 2022 at 11:34:34 UTC, rikki cattermole wrote:On 06/03/2022 12:23 AM, rempas wrote:I misread rikki's comment Loosing function overloading is indeed problematic, so it's not a so good idea..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
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
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
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" offersThere'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
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: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!Am I the only one that things this way? If I'm not wrong, other than some (mostly runtime) advantages that "betterC" offersThere'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
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 projectI 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! lolBetter C is very valuable, Rust has to go throught a lot just to provide similar functionality we get herebetterC has nothing to do with C interop.
Mar 05 2022
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
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
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
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:Which is trivially done now, whereas making it the default with betterC means you lose a bunch of D featuresBasically 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