This is the first post in a new tutorial series I'm doing on the blog. I've covered this topic elsewhere, so for most of the basics I just link to existing material. The purpose of this series is to delve into some of the trouble spots that arise from the differences between the two languages. In this post, I go through a brief tutorial to make sure that all readers at least know how to compile a C source module to an object file and link it with a D executable, then give them an opportunity to try it out by showing the potential problem with long/ulong and C.

The blog:
https://dlang.org/blog/2017/12/05/interfacing-d-with-c-getting-started/

Reddit:
https://www.reddit.com/r/programming/comments/7hqk8b/interfacing_d_with_c_getting_started/

On Tuesday, 5 December 2017 at 16:06:19 UTC, Mike Parker wrote:
> This is the first post in a new tutorial series I'm doing on the blog. I've covered this topic elsewhere, so for most of the basics I just link to existing material. The purpose of this series is to delve into some of the trouble spots that arise from the differences between the two languages. In this post, I go through a brief tutorial to make sure that all readers at least know how to compile a C source module to an object file and link it with a D executable, then give them an opportunity to try it out by showing the potential problem with long/ulong and C.
>
> The blog:
> https://dlang.org/blog/2017/12/05/interfacing-d-with-c-getting-started/
>
> Reddit:
> https://www.reddit.com/r/programming/comments/7hqk8b/interfacing_d_with_c_getting_started


Thanks.  Its something I needs to learn.

On Tuesday, 5 December 2017 at 16:06:19 UTC, Mike Parker wrote:
> This is the first post in a new tutorial series I'm doing on the blog. I've covered this topic elsewhere, so for most of the basics I just link to existing material. The purpose of this series is to delve into some of the trouble spots that arise from the differences between the two languages. In this post, I go through a brief tutorial to make sure that all readers at least know how to compile a C source module to an object file and link it with a D executable, then give them an opportunity to try it out by showing the potential problem with long/ulong and C.
>
> The blog:
> https://dlang.org/blog/2017/12/05/interfacing-d-with-c-getting-started/
>
> Reddit:
> https://www.reddit.com/r/programming/comments/7hqk8b/interfacing_d_with_c_getting_started/

Typo: substitue

I think you should change the "long" explanation to

"However, in C, they are 4 bytes"

as it may not be clear to some that you're now talking about C.

> In D, long and ulong are always 8 bytes. This lines up with most 64-bit systems under the version(Posix) umbrella, where long and unsigned long are also 8 bytes. However, they are 4 bytes on 32-bit architectures. Moreover, they’re always 4 bytes on Windows, even on a 64-bit architecture.

Why is this? How are we expected to write cross platform code with long/ulong? What are the alternatives?

On Wednesday, 6 December 2017 at 04:14:35 UTC, Arun Chandrasekaran wrote:
>> In D, long and ulong are always 8 bytes. This lines up with most 64-bit systems under the version(Posix) umbrella, where long and unsigned long are also 8 bytes. However, they are 4 bytes on 32-bit architectures. Moreover, they’re always 4 bytes on Windows, even on a 64-bit architecture.
>
> Why is this? How are we expected to write cross platform code with long/ulong? What are the alternatives?

It's right there in the blog post:

import core.stdc.config : c_ulong, clong;

On Wednesday, 6 December 2017 at 01:29:10 UTC, Joakim wrote:
>
>
> Typo: substitue

And I thought I had managed to catch everything this time. Thanks!


>
> I think you should change the "long" explanation to
>
> "However, in C, they are 4 bytes"
>
> as it may not be clear to some that you're now talking about C.

On Wednesday, 6 December 2017 at 04:27:01 UTC, Mike Parker wrote:
> On Wednesday, 6 December 2017 at 04:14:35 UTC, Arun Chandrasekaran wrote:
>>> In D, long and ulong are always 8 bytes. This lines up with most 64-bit systems under the version(Posix) umbrella, where long and unsigned long are also 8 bytes. However, they are 4 bytes on 32-bit architectures. Moreover, they’re always 4 bytes on Windows, even on a 64-bit architecture.
>>
>> Why is this? How are we expected to write cross platform code with long/ulong? What are the alternatives?
>
> It's right there in the blog post:
>
> import core.stdc.config : c_ulong, clong;

Or was the paragraph ambiguous for you? long and ulong are always 8 bytes in D. It's the C types that vary across platforms. I've updated the text as Joakim suggested for clarity.

On Wednesday, 6 December 2017 at 04:33:38 UTC, Mike Parker wrote:
> On Wednesday, 6 December 2017 at 04:27:01 UTC, Mike Parker wrote:
>> On Wednesday, 6 December 2017 at 04:14:35 UTC, Arun Chandrasekaran wrote:
>>>> [...]
>>>
>>> Why is this? How are we expected to write cross platform code with long/ulong? What are the alternatives? 99
>>
>> It's right there in the blog post:
>>
>> import core.stdc.config : c_ulong, clong;
>
> Or was the paragraph ambiguous for you? long and ulong are always 8 bytes in D. It's the C types that vary across platforms. I've updated the text as Joakim suggested for clarity.

Thanks Mike, that explains!

On Tuesday, 5 December 2017 at 16:06:19 UTC, Mike Parker wrote:
> This is the first post in a new tutorial series I'm doing on the blog.

Hi Mike,
  Nice.

It's always much easier to comment than to write an article from scratch. So take all this with a grain of salt:
Overall I find that it'd be much nicer if you focus on C-D interaction only. Currently you've added a lot of things that people really would already know before reading the text: I think preknowledge should be how to create programs in C and in D (including compilers, etc.). Especially on a second read, it's a lot of scrolling back and forth to find the good nuggets of info.

- I would make it clearer that you are discussing calling C code from a D application. If you are going to discuss the other way around too, always make it super clear in which language the "main" part of the program is. Perhaps explain the differences in how to setup a "hello world" (e.g. druntime initialization).
- I would remove all related to DMC, it's needless extra complication.
- Add a sentence that all should work identically for GDC and LDC, except for the `-m32mscoff` (I think `-m32` or `-m64` is superfluous for LDC).
- The text about "both files have the same name" is also needless, I think. You are writing a text about how to call C-code from D-code, using the commandline no less! ;-)  Instead, I would add the output filename explicitly on the cmdlines. It's short, and more clearly shows which files are created when.
- Commandline invocation and installation of compilers is mixed now;  pull it apart for clarity. Fit the installation of compilers in one or two sentences (D and C).
- typo: "offical" --> "official"
- The code fragments don't need to be packed tight. Perhaps add comments inside them, to beef them up a bit and make them stick out more.  (you could add comments about "forward declaration", "definition", ...)
- Separate the hello world example into its own section: "see how easy it is?" :-)


Ideas:
- Idea for future texts:  how to set this up using dub, and other build mechanisms like cmake, makefile, IDEs, ...
- Perhaps an example of why one might want this, external libraries is what I am thinking. Forward reference to future blog article? (dstep?)

Cheers,
  Johan

On Wednesday, 6 December 2017 at 08:20:25 UTC, Johan Engelen wrote:

> Overall I find that it'd be much nicer if you focus on C-D interaction only. Currently you've added a lot of things that people really would already know before reading the text: I think preknowledge should be how to create programs in C and in D (including compilers, etc.). Especially on a second read, it's a lot of scrolling back and forth to find the good nuggets of info.

Thanks for the feedback! I'm taking the bits about structure and layout and leaving the bits about content :-)

While combining D and C is the focus of the series, the motivation for this specific post is entirely to make sure everyone knows how to generate object files using all the different C compilers. I really want them to compile things themselves as they go along. The bit about c_ulong at the end was something I threw in as an example of what's to come.

While I would love to assume that everyone reading will already know how to work with the C command line tools, experience has shown me that is a misplaced assumption. We've got a lot of people coming to D who have never touched C or the command line, or if they have it's been in an IDE and their command line experience is limited. So my intent is to keep the command line minimal and take nothing for granted.

FYI, this started as one post that I wrote a few weeks back about C and D strings. But a series of comments here on the forums reminded me of all the issues people keep having with getting D set up on Windows (something that still baffles me, but it is what it is). Then one idea led to another and here we are, with a beginner-level tutorial as the fist post in a series.

The next few posts will focus exclusively on the details (arrays, strings, exception handling, calling conventions) and refer those who need it back to this post. I also plan to cover calling D from C, and segue in to a couple about betterC and how the absence of the runtime affects things.