Ah, I see, that makes sense. And it now compiles correctly, thanks.
I seem to have another problem with the function pointer approach. I
am trying to set up a function that would pass the function pointers
from C to D, and DMD refuses to compile it:
If I have the function pointer struct with D calling convention
pointers, like this:
struct S_FrontendFunctions
I'm trying to implement the function pointer system right now, and it
seems to work on the C side, but not D. I assume I'm missing some kind
of syntax here. I have these global variables:
struct S_FrontendFunctions {
void function() RedrawScreen;
void function(const
> However, this gets quite inefficient with a lot of different strings,
I just had an idea, perhaps it's possible to work around this
particular point by creating a wrapper function that converts the
passed variable into the C string type? The problem with this idea is
that I can't find a way to p
I'm testing how I could use globals in C, when using D as a library
and C as a frontend. So far it seems to be working well with some data
types, but not so much with a few others.
First of all, one obvious problem is strings, since they are a lot
different in D. I can transfer them with a wrapper
Is there any library that would allow me to use the extended terminal
features (like coloured backgrounds and custom/multiple resolution
support) that works with D and is not platform-dependent? Something
similar to ncurses? I know that there was a dcurses project, but it
seems that it only works w
Yeap, it's definitely a bug, and the temp file is in fact the library
that I need.
Anyway I'm trying to compile it on Windows now. However, there are two
problems. First of all, the Windows Command Prompt does not expand
wildcards, and DMD does not take it as an argument. Thus importing
LuaD as a
Anyone have any ideas about this? Or is it a bug? If I make RDMD
chatty and listing all warnings, I get these lines:
dmd -w -wi -lib -L-llua -I../include/LuaD -v -o- 'arco.d' -I'.' >arco.d.deps
dmd -w -wi -lib -L-llua -I../include/LuaD
-of'/tmp/.rdmd/home/dainius/src/arco.d.3C10152112FB7E5
A question about RDMD - can it compile libraries as well? Since right
now it compiles my library code fine, yet I get an .a file that is
mere 72 bytes of size, so I'm pretty sure that it's not what I am
supposed to be getting. The command I use to compile it is:
rdmd --build-only -lib -L-llua
Oh, so structs themselves are only definitions and not global
variables, I see. Thanks.
I seem to have run into a problem with the function pointer method
here. I have this code:
arco.d:
struct FrontendFunctions {
void function(SoundTypes) Sound_Play;
void function() RedrawScreenFull;
void function(const char*, int) PrecacheCard;
void function(Car
Yes, this is a library, so a main() there would be rather pointless.
However, it seems that on many occasions compilers will simply not
acknowledge anything without one, so I guess at least a declaration is
in order... I'll have to try that out once I get back on Windows.
Meanwhile, on Linux, I am
So, now my (static) library nearly links in Win32. There is only one
link error, and apparently it's generated by phobos:
..\lib\phobos.lib(dmain2)
Error 42: Symbol Undefined __end
Any clues about what is happening? Admittedly, that phobos.lib is from
March 20, 2011, so it's rather old b
I see. Well, I guess I'll have to stick to static ones until this gets
sorted out.
On Thu, Jul 28, 2011 at 10:37 PM, Kai Meyer wrote:
> On 07/27/2011 04:40 PM, Dainius (GreatEmerald) wrote:
>
> One reason for the confusing responses is that in your original post you
> said:
> "a frontend (a library)", "a backend (an
> executable)",
Hmm, there are still a whole lot of functions that call Shuffle(), so
it might not be ideal. However, this gives me an idea - if a pointer
to a function can be a parameter, can it be a global variable? In that
case, the frontend would indeed be able to overwrite the function that
the backend calls
No no. It's the other way round. Shuffle() is in the library
(backend). PlaySound() is in the executable (frontend). Since I don't
want the library to be dependent on any sound libraries, I can't have
PlaySound() in it. And there is no other way that I can think of to
execute PlaySound() just at th
Hm, well, at least I don't know how it's possible for a binary to
overwrite/capture a library's function. Would you care to give an
example?
I have one program design problem and I wonder if anyone here could
give any suggestions about it. The situation is like this: I am
splitting a game into a frontend (a library) and a backend (an
executable). The backend is going to handle all the game mechanics,
while the frontend is going to handl
Ah, that did the trick, thanks!
I updated the DMD and tried RDMD, but still no luck. Linker errors
galore. You can see all of them here: http://pastebin.com/C6cRVGKt
Hmm, apparently it requires a strict compilation order. If I just add
all .d files in no particular order, I get lots of linker errors, for
example:
LuaTest.o: In function
`_D4luad4base9LuaObject9checkTypeFPT4luad1c3lua9lua_StateiiPxaZv':
LuaD/luad/c/lua.d:(.text._D4luad4base9LuaObject9checkTypeFP
I must be missing something incredibly obvious here, but I can't find
out what it is... I'm trying to build a very simple test program for
LuaD, right now it simply imports the library. But it throws a linker
error for some reason. Here's the program I'm trying to compile:
import std.stdio;
According to the Derelict page, there already are unofficial bindings.
But I guess they wouldn't work with Derelict2 anyway.
I see. And what about Lua? I see lots and lots of different libraries
for that on dsource, and there is even some support in Derelict as
well. I assume that LuaD is the one in active development and most
fitting for current D2?
Can D interface with SDL directly? Right now the program I'm writing
uses C as a sort of a wrapper for D and SDL to communicate, and I
guess it would be simpler, cleaner and more reliable if D could call
SDL functions directly. If it works, is there anything I should keep
in mind about it?
> I have a related enhancement request since lot of time:
> http://d.puremagic.com/issues/show_bug.cgi?id=4716
>
> Bye,
> bearophile
>
That's exactly what I'd like to see. Voted.
After all, D is created with practicality in mind, and doing all that
parsing is the opposite of what it's trying to a
I see. Using %s does indeed work with ints, and chomp(readln()) works
with strings. It's rather counter-intuitive, though.
I wonder why there isn't a simpler way to do this, something like
writeln() - you could input the variables as parameters and it would
automatically read them...
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.
All right, found something really odd today, might be a bug. If in C I
have this:
int16_t D_getPictureCoordX(int Pool, int Card);
And in D I have this:
short D_getPictureCoordX(int Pool, int Card);
When I call D_getPictureCoord() from C, the parameters are all off, it
seems that it receives eit
Oh, never mind. About sending strings, I got it working, I just had to
create a function like this in D:
immutable(char)* GetString()
{
return StringD.toStringz();
}
As for D not compiling, I had to declare it in D, d'oh :D And that
extern is in the wrong place there.
All right, I solved that part of the problem by creating a linked
list. However, getting the string out of D is still problematic,
namely because toStringz() gives me an immutable char*, and I don't
seem to be able to pass those, since I can't assign those to immutable
variables outside their const
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.
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 ab
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?
Oh, I found the problem... It's just me forgetting that my library has
to go before phobos to compile it. So right now it works perfectly!
Thanks!
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
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 compiling
Ooh, thanks, it works! Though linking in Linux is still quite odd. So
the final code for my test program is this:
cpart.c
#include
extern int ResultD;
int Process(int Value);
int rt_init();
int rt_term();
void LinuxInit();
int main()
{
int num;
rt_init(); //I
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 havi
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;
41 matches
Mail list logo
