Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I wanted to like D for a long time, feels like Go without the limitations to me.

But it's taking A LONG TIME to become usable.




I found the importC feature interesting, I tried the example code (with running the hello world in C using the importC flag) and the compiler threw lots of warnings.

https://dlang.org/spec/importc.html#examples


I did not get any warnings running it on Ubuntu.

What warnings are you seeing? What operating system?


Thanks for checking up,

I did it on my Winows 10 machine, it's kinda too late to start it up now and run it but I'll do it tomorrow and post both the code and the error message.

Update: I did this quickly on my MBP.

Code: #include <stdio.h> #include <stdlib.h>

int main() { puts("Hello, world!"); return EXIT_SUCCESS; }

Command: dmd test.c

Error: ld: address=0x0 points to section(2) with no content in '/Users/james/.asdf/installs/dmd/2.107.0/dmd2/osx/lib/libphobos2.a[3233](config_a98_4c3.o)' clang: error: linker command failed with exit code 1 (use -v to see invocation) Error: linker exited with status 1


I'm wondering why you're linking with an OSX library on Windows 10!


I’m not, sorry for the confusion. I compiled the code on my macbook instead because it was too late to start my win 10 computer.

I think windows threw a similar error.


I added your code to the D test suite. It passes on all supported platforms, including Windows and OSX. I am at a loss why it isn't working for you.

https://github.com/dlang/dmd/pull/16238


Here's the pipeline spitting out the same error as on my macbook did.

https://github.com/dlang/dmd/actions/runs/8023469412/job/219...


Thank you. Did you mean to #include stdio.h twice?


No I did not mean to include stdio.h twice. I don’t think I am doing that either?


Sorry, my bad, I misread it.


On my windows machine, running the following code:

#include <stdio.h>

#include <stdlib.h>

int main()

{

puts("Hello, world");

return EXIT_SUCCESS;

}

with the following command:

dmd main.c

gives the following error:

main.c(1): Error: C preprocessor directive `#include` is not supported

main.c(1): Error: no type for declarator before `#`

main.c(2): Error: C preprocessor directive `#include` is not supported

main.c(7): Error: no type for declarator before `return`

main.c(8): Error: no type for declarator before `}`

Running the c code using docker just says that it cannot process c extensions.

docker run --rm -it -v .:/src dlanguage/dmd dmd main.c


You might be using an older version of dmd. ImportC's support for the preprocessor is fairly new.


I got it to work on my Windows machine.

The solution was that I had to install Visual studio and add the workload (plugin?) "Desktop development with c++".

The only thing needed to be checked was "MSVC v143" and "Windows 11 SDK", the rest is bloat.

After that I had to put the following path from Visual studio "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.31.31103\bin\Hostx64\x64" into my PATH.

This is because I needed the "cl.exe", "sal.h" and probably a couple of other files to be available to dmd.

(Also, the outdated version of dmd was another factor of the issue)

Finally, the compilation with main.c went smoothly. I had no idea the compiler needed external tooling, I thought it was self sufficient.


> I had no idea the compiler needed external tooling, I thought it was self sufficient.

It used to be self-sufficient. But, we had to give up on our linker because we didn't have the staff to keep a linker up to date, and decided to stop chasing windmills and just use what was available. ImportC, in order to work, needs a preprocessor. We do have our own Standard compliant preprocessor, but it had a major problem. All the C preprocessors predefine a ton of macros (cpp predefines up to 400 macros). Different combinations of compiler switches turn on or off those predefines in poorly and usually undocumented ways. It differs from preprocessor to preprocessor, and was a hopeless nightmare.

So, ImportC uses the C preprocessor of the associated C compiler, and that works like a champ. The downside is you'll need to have that preprocessor installed and on the path.


I appreciate the explanation, that makes total sense.

The burden to maintain such a preprocessor doesn’t seem that rewarding compared to using existing ones.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: