www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Interfacing D with C: Getting Started

reply Mike Parker <aldacron gmail.com> writes:
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/
Dec 05 2017
next sibling parent aberba <karabutaworld gmail.com> writes:
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.
Dec 05 2017
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
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.
Dec 05 2017
parent Mike Parker <aldacron gmail.com> writes:
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.
Dec 05 2017
prev sibling next sibling parent reply Arun Chandrasekaran <aruncxy gmail.com> writes:
 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?
Dec 05 2017
parent reply Mike Parker <aldacron gmail.com> writes:
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;
Dec 05 2017
parent reply Mike Parker <aldacron gmail.com> writes:
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.
Dec 05 2017
parent Arun Chandrasekaran <aruncxy gmail.com> writes:
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!
Dec 05 2017
prev sibling parent reply Johan Engelen <j j.nl> writes:
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
Dec 06 2017
parent Mike Parker <aldacron gmail.com> writes:
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.
Dec 06 2017