AFAIK 'int' in D is always a 32-bit value. But in C, 'int' could be
64bit on 64bit platforms. You could try printing sizeof(int) in C and
compare that to int.sizeof in D and see if they match. You probably
know this, but make sure your exported D function is annotated with
extern(C).
They both return 4, and both short and int16_t return 2.
Also, I've noticed that if I use a struct (of four ints) instead, the
same thing happens, the parameters are not correct. And yes, of course
they are extern already.
OK, now I have a question about passing variables. In D, I have a
dynamic array of strings and I want C to get that array. Yet C
supports neither dynamic arrays nor strings. So is there a way to
accomplish this?
Dainius (GreatEmerald):
OK, now I have a question about passing variables. In D, I have a
dynamic array of strings and I want C to get that array. Yet C
supports neither dynamic arrays nor strings. So is there a way to
accomplish this?
To use a D data structure from C you need first of all
Well, the situation is like this: D creates a list of names of files
that should be loaded by C. C then takes the list, uses it to load the
files, then stores both the pointers to the loaded files and the names
of the files in an array of structs. Then when C wants to access the
files, it asks D
Dainius (GreatEmerald):
Well, the situation is like this: D creates a list of names of files
that should be loaded by C. C then takes the list, uses it to load the
files, then stores both the pointers to the loaded files and the names
of the files in an array of structs. Then when C wants to
Hmm, if I was to do it from C, I would have to deal with all the
allocation, since I don't know how large the array is going to be when
it's complete, while D doesn't need to know since it uses dynamic
arrays.
Ah, including pthread indeed works, but now I've run into another
problem related to Linux and architecture. I want to use D for my
program that also uses things like SDL and Lua. Earlier when I
compiled it, I always did so with 64-bit libraries. But D is so far
only in 32-bits, thus when
Dainius (GreatEmerald) Wrote:
Ah, including pthread indeed works, but now I've run into another
problem related to Linux and architecture. I want to use D for my
program that also uses things like SDL and Lua. Earlier when I
compiled it, I always did so with 64-bit libraries. But D is so far
Hmm... Spent a few hours trying to figure out how to update GCC and
all to conform to the requirements for 2.0.52, and at seems that it
compiles my small test program just fine, but it fails on compiling
the main project for some reason. And the linker outputs
half-scrambled things. Anyway, here's
On 3/23/2011 3:22 AM, Dainius (GreatEmerald) wrote:
Though I find it quite odd that I need workarounds like those to
compile on Linux, but ah well, it works, at least. Also odd that I
can't link using GCC on Linux, it gives me a long list of undefined
references (it seems that they are all
I've tried compiling the same on Linux and the program still crashes
(with segmentation fault there). No error message or anything. And it
doesn't matter if I compile the thing from .obj or from .lib files, I
still get the same crashes. So it's a real showtopper for me, since
what's the use of
On 3/22/2011 6:46 PM, Dainius (GreatEmerald) wrote:
I've tried compiling the same on Linux and the program still crashes
(with segmentation fault there). No error message or anything. And it
doesn't matter if I compile the thing from .obj or from .lib files, I
still get the same crashes. So it's
Now I'm trying to do something more complicated, and it seems that while
importing works (it compiles and links fine), actually using the imported
things or pretty much anything that D offers makes the program crash. For
instance, in the D part:
---
module dpart;
import std.stdio;
On 02/07/2011 07:53 AM, GreatEmerald wrote:
Hmm, no, it won't work right on Linux for some reason. This is the output:
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../libphobos2.a(deh2_4e7_525.o): In
function `_D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable':
On 2011-02-07 07:32, GreatEmerald wrote:
All right, found out how to make it compile. There are two ways:
1) Using DMD for the D part, DMC for the C part and combining them. This is
the batch file I use for that:
dmd -c -lib dpart.d
dmc cpart.c dpart.lib phobos.lib
2) Using DMD for the D
Everything is right from what I can tell. This is the code I use for the D part:
module dpart;
import std.c.stdio;
extern(C):
shared int ResultD;
int Process(int Value)
{
printf(You have sent the value: %d\n, Value);
ResultD = (Value % 5);
return ResultD;
On Mon, 07 Feb 2011 06:42:46 -0500, spir denis.s...@gmail.com wrote:
On 02/07/2011 07:53 AM, GreatEmerald wrote:
Hmm, no, it won't work right on Linux for some reason. This is the
output:
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../libphobos2.a(deh2_4e7_525.o):
In
function
On 2/7/11, GreatEmerald past...@gmail.com wrote:
in Windows I am required to explicitly tell DMD to compile
phobos.lib, but
not in Linux. Quite odd.
Check the sc.ini file in dmd/windows/bin, make sure it has at least
this for the LIB variable:
LIB=%@P%\..\lib;
On Mon, 07 Feb 2011 10:28:41 -0500, GreatEmerald past...@gmail.com wrote:
Everything is right from what I can tell. This is the code I use for the
D part:
module dpart;
import std.c.stdio;
extern(C):
shared int ResultD;
int Process(int Value)
{
printf(You have sent the
OK, well this is interesting... I managed to compile it but it's quite odd. In
order to do that, I added a call to main() in my Process() function, and then
added an empty main() in the D part before extern(C). It seems that there are
no
conflicts, too.
Andrej, that line is there. But it really
On 02/07/2011 04:32 PM, Steven Schveighoffer wrote:
On Mon, 07 Feb 2011 06:42:46 -0500, spir denis.s...@gmail.com wrote:
On 02/07/2011 07:53 AM, GreatEmerald wrote:
Hmm, no, it won't work right on Linux for some reason. This is the output:
On Mon, 07 Feb 2011 13:53:14 -0500, spir denis.s...@gmail.com wrote:
On 02/07/2011 04:32 PM, Steven Schveighoffer wrote:
On Mon, 07 Feb 2011 06:42:46 -0500, spir denis.s...@gmail.com wrote:
On 02/07/2011 07:53 AM, GreatEmerald wrote:
Hmm, no, it won't work right on Linux for some reason.
All right, found out how to make it compile. There are two ways:
1) Using DMD for the D part, DMC for the C part and combining them. This is
the batch file I use for that:
dmd -c -lib dpart.d
dmc cpart.c dpart.lib phobos.lib
2) Using DMD for the D part, DMC for the C part, DMD for combining
Hmm, no, it won't work right on Linux for some reason. This is the output:
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../libphobos2.a(deh2_4e7_525.o): In
function `_D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable':
On 1/19/11, GreatEmerald past...@gmail.com wrote:
All right, it worked, when the D side is this:
module techborg;
import std.c.stdio;
extern(C):
shared int ResultD;
int Process(int Value)
{
printf(You have sent the value: %d\n, Value);
ResultD = (Value % 5);
Hmm, not being able to use D function kinda defeats the purpose of using it in
the
first place. Ah well, let's see if people know more about this elsewhere.
Anyway, I'm trying to compile this under Linux now. DMD works brilliantly and I
get techborg.a file. I do this (using Debian x64):
$ gcc
Ah, I see, thanks! I'll try that.
While I don't have a problem with using DMC, but others who are willing to join
my
project might have one... Right now I'm using MinGW, so it would definitely be
useful to know how to convert the libraries to the format it understands...
Though
from the looks
On 1/17/11, GreatEmerald past...@gmail.com wrote:
Ah, I see, thanks! I'll try that.
While I don't have a problem with using DMC, but others who are willing to
join my
project might have one... Right now I'm using MinGW, so it would definitely
be
useful to know how to convert the libraries
Also make sure you use globals properly if you use them (shared,
__gshared, etc.)
Of course!
dstatic.d:
module dstatic;
extern(C):
int add(int x, int y)
{
return x + y;
}
Then compile with:
dmd -lib dstatic.d
driver.c:
#include stdio.h
int main()
{
printf(add(4, 5) = %d, add(4, 5));
}
dmc driver.c dstatic.lib
driver.exe
add(4, 5) = 9
The problem (on Windows), is that the static lib is in the OMF format,
and modern tools like VC or MinGW won't be able to read those, because
they use COFF instead. So you would have to convert from OMF to COFF.
But on Linux I think DMD uses the standard Linux object file format,
so I don't think
On 01/16/2011 03:34 PM, Andrej Mitrovic wrote:
The problem (on Windows), is that the static lib is in the OMF format,
and modern tools like VC or MinGW won't be able to read those, because
they use COFF instead. So you would have to convert from OMF to COFF.
But on Linux I think DMD uses the
On 01/16/2011 05:04 PM, Ellery Newcomer wrote:
On 01/16/2011 03:34 PM, Andrej Mitrovic wrote:
The problem (on Windows), is that the static lib is in the OMF format,
and modern tools like VC or MinGW won't be able to read those, because
they use COFF instead. So you would have to convert from
I've just realized I didn't even prototype the function in the C
module. DMC doesn't warn about this, it seems. Not even with the -A
(ANSI C) flag. It won't even warn me when I prototype the function and
pass doubles instead of ints. Maybe I didn't enable all warnings?
(I've used: dmc -wc -v2 -A).
35 matches
Mail list logo
