Cause I can't find an option in the latest DMD release and because the ImportC page seems to be incomplete (even saying it's under construct), I'm wondering if ImportC exists even as prototype but it's hidden or if it's not available at all. Anyone knows?
Thread overview | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
October 15, 2021 Can we use "ImportC" used yet? | ||||
---|---|---|---|---|
| ||||
October 15, 2021 Re: Can we use "ImportC" used yet? | ||||
---|---|---|---|---|
| ||||
Posted in reply to rempas | On Friday, 15 October 2021 at 18:39:10 UTC, rempas wrote: >Cause I can't find an option in the latest DMD release and because the ImportC page seems to be incomplete (even saying it's under construct), I'm wondering if ImportC exists even as prototype but it's hidden or if it's not available at all. Anyone knows? There's no option, you just use a normal import statement when the module is named .c instead of .d I say 'just' but typical C uses the C preprocessor and can't be imported as-is. Here's an example in three files:
this is importing sys_stat.c , making space on the stack for a stat_t (what's that?), calling fstat on fd 0, and then writing the output, which might look like
the d programmer did not have to carefully The next inconvenient thing is: what about when you want a c
Of course you can rename when importing as usual, or have a separate .d module that cleans this interface up where the C preprocessor can't interfere. For function-like In conclusion, ImportC exists and you can use it, and complications like smuggling structs are discussed in that page. If you're going to wrap a new C library especially, it can take on 99% the tedium for you. If you're going to burn down an importc-by-hand work that you have already and replace it with ImportC, it might be better to wait for dub and gdc to catch up. As annoying as it might be to have C constants in your code, they do compile with fewer build steps. |
October 15, 2021 Re: Can we use "ImportC" used yet? | ||||
---|---|---|---|---|
| ||||
Posted in reply to jfondren | On Friday, 15 October 2021 at 20:45:35 UTC, jfondren wrote: >
the d programmer did not have to carefully Speaking of padding the struct, what's what
yeah, core.sys.posix.sys.stat doesn't account for that. |
October 16, 2021 Re: Can we use "ImportC" used yet? | ||||
---|---|---|---|---|
| ||||
Posted in reply to jfondren | On Friday, 15 October 2021 at 20:45:35 UTC, jfondren wrote: >There's no option, you just use a normal import statement when the module is named .c instead of .d I say 'just' but typical C uses the C preprocessor and can't be imported as-is. [ ... ] First of all, I see you answering questions (not only mine) very often so thanks ;). Now, I tried to do what you said but I'm getting an error. Now I'm just give you the code so you can also check it (if you want of course) and see what's going on. Let's see:
After that, I'm using:
Checking the actual source code, it seems like a parsing error. Any ideas? >The next inconvenient thing is: what about when you want a c
Of course you can rename when importing as usual, or have a separate .d module that cleans this interface up where the C preprocessor can't interfere. For function-like In conclusion, ImportC exists and you can use it, and complications like smuggling structs are discussed in that page. If you're going to wrap a new C library especially, it can take on 99% the tedium for you. If you're going to burn down an importc-by-hand work that you have already and replace it with ImportC, it might be better to wait for dub and gdc to catch up. As annoying as it might be to have C constants in your code, they do compile with fewer build steps. Agree, having to do it manually will just be a pain in the ass... |
October 16, 2021 Re: Can we use "ImportC" used yet? | ||||
---|---|---|---|---|
| ||||
Posted in reply to rempas | On Saturday, 16 October 2021 at 06:39:46 UTC, rempas wrote: >
After that, I'm using:
These are __restrict errors again, but then I get a bunch of others as well. This test_og.c works (while obviously breaking some bswap functions):
It would be less annoying to compile the original test_og.o with gcc and then link it in. |
October 16, 2021 Re: Can we use "ImportC" used yet? | ||||
---|---|---|---|---|
| ||||
Posted in reply to jfondren | On Saturday, 16 October 2021 at 07:09:16 UTC, jfondren wrote: >This test_og.c works (while obviously breaking some bswap functions): I don't know if I should have known that but what is "bswap"? >It would be less annoying to compile the original test_og.o with gcc and then link it in. If I understand correctly you mean compile the original file with gcc ( |
October 16, 2021 Re: Can we use "ImportC" used yet? | ||||
---|---|---|---|---|
| ||||
Posted in reply to rempas | On Saturday, 16 October 2021 at 08:19:41 UTC, rempas wrote: >On Saturday, 16 October 2021 at 07:09:16 UTC, jfondren wrote: >This test_og.c works (while obviously breaking some bswap functions): I don't know if I should have known that but what is "bswap"? I came up with those
initially those were defined in terms of compiler intrinsics that d doesn't know about, and since they're not needed for your use, I fixed this in the direction of making them no-ops. They're part of stdlib.h, probably. What they do is endian swaps, like the stuff in std.bitmanip > >It would be less annoying to compile the original test_og.o with gcc and then link it in. If I understand correctly you mean compile the original file with gcc ( importC is a new option, but it doesn't make old options go away, and in this specific case an older option would've been less trouble. That's all I'm saying. |
October 16, 2021 Re: Can we use "ImportC" used yet? | ||||
---|---|---|---|---|
| ||||
Posted in reply to jfondren | On Saturday, 16 October 2021 at 11:03:06 UTC, jfondren wrote: >I came up with those
initially those were defined in terms of compiler intrinsics that d doesn't know about, and since they're not needed for your use, I fixed this in the direction of making them no-ops. They're part of stdlib.h, probably. What they do is endian swaps, like the stuff in std.bitmanip Cool! It now makes sense now. >importC is a new option, but it doesn't make old options go away, and in this specific case an older option would've been less trouble. That's all I'm saying. Yeah agree, new options are a lot of times not there to make old options obsolete and not used. Tho in this case, I think ImportC will always makes sense against the old way of doing things. Even if you have to do a little bit of work, it will still be nothing compared if you had to make manual binding yourself... Thanks a lot for the help, have an amazing day!! |
October 17, 2021 Re: Can we use "ImportC" used yet? | ||||
---|---|---|---|---|
| ||||
Posted in reply to rempas | On Saturday, 16 October 2021 at 08:19:41 UTC, rempas wrote: >On Saturday, 16 October 2021 at 07:09:16 UTC, jfondren wrote: While we're on this subject, I've been having similar issues now tried compiling @rempas's example file with:
and get the response:
Platform is Ubuntu 20.04 gcc version 9.30 and dmd version v2.098.0. At first I tried compiling a script with fftw3 and thought it was something wrong with my script but when I tried it with your example, the same thing happened. |
October 17, 2021 Re: Can we use "ImportC" used yet? | ||||
---|---|---|---|---|
| ||||
Posted in reply to data pulverizer | On Sunday, 17 October 2021 at 02:45:03 UTC, data pulverizer wrote: >While we're on this subject, I've been having similar issues now tried compiling @rempas's example file with:
and get the response:
You're not doing this with the files in the thread, or you'd get
as test.d is still importing test_c.c, a different file from test_og.o I get your error if the original test_og.c is used but test.d is modified to import test_og.c:
In this case, your compilation to test_og.o doesn't matter; D is still trying to import test_og.c, and since that file has CPP To link in a C object rather than use importC, you'd need this test.d:
With which:
|