On Thursday, 17 December 2015 at 06:04:14 UTC, Jeremy DeHaan
wrote:
And I guess what I was talking about before is that using a
factory method feels klunky to me. If the things I am wrapping
had been written in D they could use default initialization, so
it feels wrong to do otherwise. I also j
On Thursday, 17 December 2015 at 04:59:20 UTC, Jakob Ovrum wrote:
On Thursday, 17 December 2015 at 04:05:30 UTC, Jeremy DeHaan
wrote:
http://dpaste.com/3FH3W13
Also, I would be wary of lazy initialization. We have bad
experiences with it for AAs and standard containers. A typical
example wou
On Thursday, 17 December 2015 at 04:05:30 UTC, Jeremy DeHaan
wrote:
Thanks. I guess what bugs me is that I always try to hide the
fact that the API is a wrapper around C stuff, ie, I want to
make people feel as though they're using idiomatic D. Doing
something like this makes it feel like less
On Thursday, 17 December 2015 at 04:05:30 UTC, Jeremy DeHaan
wrote:
http://dpaste.com/3FH3W13
Also, I would be wary of lazy initialization. We have bad
experiences with it for AAs and standard containers. A typical
example would be:
void foo(Wrapper w)
{
...
w.doTheThing();
...
On Thursday, 17 December 2015 at 03:43:58 UTC, Jakob Ovrum wrote:
On Thursday, 17 December 2015 at 03:31:37 UTC, Jeremy DeHaan
wrote:
Hi all. I'm interfacing to some C code which include an opaque
type and some C functions that create and work with a pointer
to that type. I want to wrap up ever
On Thursday, 17 December 2015 at 03:31:37 UTC, Jeremy DeHaan
wrote:
Hi all. I'm interfacing to some C code which include an opaque
type and some C functions that create and work with a pointer
to that type. I want to wrap up everything in a struct, and the
only thing that seems to bug me is ini
Hi all. I'm interfacing to some C code which include an opaque
type and some C functions that create and work with a pointer to
that type. I want to wrap up everything in a struct, and the only
thing that seems to bug me is initialization.
Since it is C code, I obviously can't read the functio
On Saturday, 1 August 2015 at 04:11:02 UTC, Laeeth Isharc wrote:
Walter observes that if you are a Java programmer and start
writing D, you will write D like you write Java. And so I
suppose one will see what one doesn't have in Java, but not so
much the benefits of D. That's true of other la
On Friday, 31 July 2015 at 21:35:30 UTC, Kyoji Klyden wrote:
On Friday, 31 July 2015 at 19:13:18 UTC, Laeeth Isharc wrote:
On Friday, 31 July 2015 at 17:14:29 UTC, Kyoji Klyden wrote:
On Friday, 31 July 2015 at 16:09:23 UTC, bachmeier wrote:
On Friday, 31 July 2015 at 03:30:20 UTC, Kyoji Klyde
On Friday, 31 July 2015 at 19:13:18 UTC, Laeeth Isharc wrote:
On Friday, 31 July 2015 at 17:14:29 UTC, Kyoji Klyden wrote:
On Friday, 31 July 2015 at 16:09:23 UTC, bachmeier wrote:
On Friday, 31 July 2015 at 03:30:20 UTC, Kyoji Klyden wrote:
So idk, it feels silly and counterproductive to have
On Friday, 31 July 2015 at 17:14:29 UTC, Kyoji Klyden wrote:
On Friday, 31 July 2015 at 16:09:23 UTC, bachmeier wrote:
On Friday, 31 July 2015 at 03:30:20 UTC, Kyoji Klyden wrote:
So idk, it feels silly and counterproductive to have D not
able to natively use C libraries. Are we just gonna have
On Friday, 31 July 2015 at 16:09:23 UTC, bachmeier wrote:
On Friday, 31 July 2015 at 03:30:20 UTC, Kyoji Klyden wrote:
So idk, it feels silly and counterproductive to have D not
able to natively use C libraries. Are we just gonna have to
write D bindings to every notable library out there? Also
On Friday, 31 July 2015 at 03:30:20 UTC, Kyoji Klyden wrote:
So idk, it feels silly and counterproductive to have D not able
to natively use C libraries. Are we just gonna have to write D
bindings to every notable library out there? Also I don't see
how it'd be problematic, if you don't want a
On Thursday, 30 July 2015 at 11:32:10 UTC, bachmeier wrote:
On Thursday, 30 July 2015 at 01:14:06 UTC, Mike Parker wrote:
On Wednesday, 29 July 2015 at 18:42:45 UTC, Kyoji Klyden wrote:
Thanks for the replies,
This issue really highlights one of D's weak points I think.
I've atleast got a rou
On 2015-07-29 20:42, Kyoji Klyden wrote:
Thanks for the replies,
This issue really highlights one of D's weak points I think.
I've atleast got a round about solution almost working. :P
You might want to check out Calypso [1] as well.
[1]
http://forum.dlang.org/thread/nsjafpymezlqdknmn...@fo
On Thursday, 30 July 2015 at 01:14:06 UTC, Mike Parker wrote:
On Wednesday, 29 July 2015 at 18:42:45 UTC, Kyoji Klyden wrote:
Thanks for the replies,
This issue really highlights one of D's weak points I think.
I've atleast got a round about solution almost working. :P
Really? I see it as on
On Wednesday, 29 July 2015 at 18:42:45 UTC, Kyoji Klyden wrote:
Thanks for the replies,
This issue really highlights one of D's weak points I think.
I've atleast got a round about solution almost working. :P
Really? I see it as one of D's strengths. It's much easier to
connect D with C than
Thanks for the replies,
This issue really highlights one of D's weak points I think.
I've atleast got a round about solution almost working. :P
On Wednesday, 29 July 2015 at 17:59:26 UTC, Kyoji Klyden wrote:
How would I use a C function that's returning a struct? auto
doesn't work here, and from what I can tell D can't import C
headers. (If it really can't then, that would be a very welcome
feature)
I do have the required libs but I
On 07/29/2015 10:59 AM, Kyoji Klyden wrote:
> How would I use a C function that's returning a struct?
The binding file must have a matching D struct.
> auto doesn't
> work here, and from what I can tell D can't import C headers. (If it
> really can't then, that would be a very welcome feature)
On Wednesday, 29 July 2015 at 17:59:26 UTC, Kyoji Klyden wrote:
How would I use a C function that's returning a struct? auto
doesn't work here, and from what I can tell D can't import C
headers. (If it really can't then, that would be a very welcome
feature)
I do have the required libs but I
How would I use a C function that's returning a struct? auto
doesn't work here, and from what I can tell D can't import C
headers. (If it really can't then, that would be a very welcome
feature)
I do have the required libs but I can't create my D obj file so I
can't really get there.
I know
On Saturday, 11 July 2015 at 01:22:14 UTC, mzf wrote:
win7 x86 dmd2.067.1 ok
ubuntu x64 dmd2.067.1 error
-
import std.stdio;
import std.socket;
extern(C)
void recv()
{
writeln("recv...");
}
extern(C)
void send()
{
writeln("sen
win7 x86 dmd2.067.1 ok
ubuntu x64 dmd2.067.1 error
-
import std.stdio;
import std.socket;
extern(C)
void recv()
{
writeln("recv...");
}
extern(C)
void send()
{
writeln("send...");
}
int main(string[] argv)
{
//copy from
On Friday, 10 July 2015 at 08:54:57 UTC, Andrea Fontana wrote:
Is there any tool out there that automatically creates D
wrappers from C headers`?
https://github.com/jacob-carlborg/dstep ?
Great! I'll try that!
On Friday, 10 July 2015 at 08:42:06 UTC, Per Nordlöw wrote:
On Friday, 10 July 2015 at 03:18:23 UTC, Mike Parker wrote:
[1]http://dlang.org/interfaceToC.html
Is there any tool out there that automatically creates D
wrappers from C headers`?
https://github.com/jacob-carlborg/dstep ?
On Friday, 10 July 2015 at 03:18:23 UTC, Mike Parker wrote:
[1]http://dlang.org/interfaceToC.html
Is there any tool out there that automatically creates D wrappers
from C headers`?
On Friday, 10 July 2015 at 03:18:23 UTC, Mike Parker wrote:
You should just be able to replace `[4]` with `*` in the
arguments.
[1]http://dlang.org/interfaceToC.html
Great!
One more thing: How shall my call to `avg_image_copy()` (from D)
look then? Is the slicing syntax `[0 .. 4]` I use abo
On Thursday, 9 July 2015 at 17:42:33 UTC, Alex Parrill wrote:
On Thursday, 9 July 2015 at 17:11:36 UTC, Per Nordlöw wrote:
On Thursday, 9 July 2015 at 16:12:27 UTC, Timon Gehr wrote:
No. You'll need explicit pass by reference on the D side.
So, how should I modify my call to `image_copy` with
On Thursday, 9 July 2015 at 17:11:36 UTC, Per Nordlöw wrote:
On Thursday, 9 July 2015 at 16:12:27 UTC, Timon Gehr wrote:
No. You'll need explicit pass by reference on the D side.
So, how should I modify my call to `image_copy` with respect to
the four first parameters?
In C, array parameter
On Thursday, 9 July 2015 at 16:12:27 UTC, Timon Gehr wrote:
No. You'll need explicit pass by reference on the D side.
So, how should I modify my call to `image_copy` with respect to
the four first parameters?
On 07/09/2015 05:19 PM, "Nordlöw" wrote:
Given
extern(C):
struct AVFrame
{
uint8_t*[AV_NUM_DATA_POINTERS] data;
int[AV_NUM_DATA_POINTERS] linesize;
int width, height;
...
}
void av_image_copy(ubyte *[4] dst_d
On Thursday, 9 July 2015 at 15:19:41 UTC, Nordlöw wrote:
uint8_t*[AV_NUM_DATA_POINTERS] data;
int[AV_NUM_DATA_POINTERS] linesize;
Forgot
enum AV_NUM_DATA_POINTERS = 8;
Given
extern(C):
struct AVFrame
{
uint8_t*[AV_NUM_DATA_POINTERS] data;
int[AV_NUM_DATA_POINTERS] linesize;
int width, height;
...
}
void av_image_copy(ubyte *[4] dst_data, int[4] dst_linesizes,
const ubyte *[4] src_data
On Wed, 22 Apr 2015 02:14:40 -0400, Dan Olson
wrote:
bitwise writes:
I am trying to interface to C++, and getting linker errors. Below are
my 3 source files and 2 build scripts with their associated
errors. Can anyone see what I'm doing wrong?
Hi, I think both examples need libstdc++ adde
bitwise writes:
> I am trying to interface to C++, and getting linker errors. Below are
> my 3 source files and 2 build scripts with their associated
> errors. Can anyone see what I'm doing wrong?
Hi, I think both examples need libstdc++ added when you link
(-L-lstdc++). That should resolve the
d Foo(){
printf("Foobar\n");
}
};
Test* CreateTest() {
return new Test;
}
void DestroyTest(Test *test) {
delete test;
}
/ Test.d
module TestMod;
extern(C++) {
interface Test {
void Foo();
}
Test CreateTest(
On 2015-03-19 13:22:44 +, Benjamin Thaut said:
Generally don't expect to many things to work with DLLs at the moment.
Hi, well, I think what's available is good enough to get most things done.
Generally speaking only exporting global functions works. Don't try to
export classes / structs
On Thursday, 19 March 2015 at 12:58:42 UTC, Robert M. Münch wrote:
On 2015-03-18 21:50:39 +, Adam D. Ruppe said:
It will not work because a function with an auto return value
is actually a template, and unused templates won't be put into
a dll.
Ok, that makes it clear. Thanks.
Generall
On 2015-03-18 21:50:39 +, Adam D. Ruppe said:
It will not work because a function with an auto return value is
actually a template, and unused templates won't be put into a dll.
Ok, that makes it clear. Thanks.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
On Wednesday, 18 March 2015 at 15:50:16 UTC, Robert M. Münch
wrote:
struct1 is visible in the DLL, struct2 is not visible in the
DLL.
It will not work because a function with an auto return value is
actually a template, and unused templates won't be put into a dll.
Windows, 32-Bit, DLL:
export extern(C) struct1 struct1(){
struct1 x;
return(x);
}
export extern(C) auto struct2(){
struct1 x;
return(x);
}
struct1 is visible in the DLL, struct2 is not visible in the DLL.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
T/cprog-897189.o
/usr/lib/libSystem.dylib
/usr/lib/system/libcache.dylib
/usr/lib/system/libcommonCrypto.dylib
...
dprog.a(dprog_1_487.o)
dprog.a(dprog_2_495.o)
cprog.c includes two symbols exported from dprog.a, which uses
the extern(C) keyword on the two functions exported from dprog.a
wh
is is a binding
extern( C ) void do_something( const( char )* str );
// capiwrapper.d -- this is a wrapper
void doSomething( string str )
{
import std.string : toStringz;
do_something( str.toStringz() );
}
That's all there is to it. The binding allows you to call C
functions from D
being passed to a C API, they *have* to be extern( C ) -- i.e.
they have to have the same calling convention that the C library
expects. If the library functions used the stdcall calling convention
rather than cdecl, then the callbacks would have to be extern( Windows
). So even a wrapper that allow
to be
extern( C ) -- i.e. they have to have the same calling
convention that the C library expects. If the library functions
used the stdcall calling convention rather than cdecl, then the
callbacks would have to be extern( Windows ). So even a wrapper
that allows you to pass D delegates or fun
On 1/4/2015 1:34 PM, WhatMeWorry wrote:
Maybe GLFW callback functions can't handled through Derelict GLFW?
And just to be clear, because the pointers to the callback functions are
being passed to a C API, they *have* to be extern( C ) -- i.e. they have
to have the same calling conve
On 1/4/2015 1:34 PM, WhatMeWorry wrote:
Now it resizes the screen successfully, but I feel like I've failed by
using extern (C) nothrow. Shouldn't Derelict GLFW be providing a D
interface?
Maybe GLFW callback functions can't handled through Derelict GLFW?
Derelict provides
indowResizeCallback);
however, I kept getting the following compiler error:
Error1Error: function pointer glfwSetWindowSizeCallback
(GLFWwindow*, extern (C) void function(GLFWwindow*, int, int) nothrow)
is not callable using argument types (GLFWwindow*, void
function(GLFWwindow* window, in
I kept getting the following compiler error:
Error 1 Error: function pointer glfwSetWindowSizeCallback
(GLFWwindow*, extern (C) void function(GLFWwindow*, int, int)
nothrow)
is not callable using argument types (GLFWwindow*, void
function(GLFWwindow* window, int width, int height))
Well, I was able t
Thank you!!!
All I have to do is
> -Original Message-
> From: digitalmars-d-learn@puremagic.com
> Sent: Mon, 15 Dec 2014 17:54:51 +
> To: digitalmars-d-learn@puremagic.com
> Subject: Re: Problem calling extern(C) function
>
> On Monday, 15 December 2014 at 17:
On Monday, 15 December 2014 at 17:48:32 UTC, AuoroP via
Digitalmars-d-learn wrote:
ulong jpegSize,
Without looking too closely, this sets off an alarm to me: C's
long and D's long are not really compatible because C's long has
variable size and D's long is 64 bit.
I'd say try "import co
. I don't that is me because I call with
extern(C) my .lst names are not mangled that way:
_tjDecompressHeader2, _tjGetErrorStr, _tjInitDecompress.
Even if you can't help, Thanks for reading this far!
This message is kinda long so here's a TOC
The code
The output
DL
On Saturday, 13 December 2014 at 19:03:42 UTC, aldanor wrote:
If I now want to have exactly the same module but with all
function declarations wrapped as described above, I have to
public import it in another module and then do some template
magic. However, it wouldn't be possible to retain the
On 12/14/2014 4:03 AM, aldanor wrote:
However, it wouldn't be
possible to retain the same function names since they've been imported
to the namespace (it's then also not possible to extern them as private
initially since then you won't be able to import/wrap them in a
different module). Hence t
On Saturday, 13 December 2014 at 19:03:42 UTC, aldanor wrote:
Let's say there's a "foo.d" that contains raw bindings to
"foo.h" (enums, structs, extern variables, function
declarations, a whole load of stuff) -- everything but the
functions is already fine but all functions need to be wrapped.
Personally i wouldn't go this route. I would create foo.d as a
C to D translation only so it can be imported and used like in
C. Then i would create another module which imports this to
create your new OOP API adding features and excepions, etc.
This allows the best of both worlds, keep the C
d then gets the exception info via C API).
My current naive solution looks like this:
/* foo.h */
int f1(...);
int f2(...);
*** foo.d ***
private extern (C) nothrow {
pragma(mangle, "f1")
int c_f(...);
public alias errorCheck!c_f1 f1;
pragma(mangle, "f2")
rent naive solution looks like this:
/* foo.h */
int f1(...);
int f2(...);
*** foo.d ***
private extern (C) nothrow {
pragma(mangle, "f1")
int c_f(...);
public alias errorCheck!c_f1 f1;
pragma(mangle, "f2")
int c_f2(...);
public alias errorCheck!c_f2 f2;
}
This w
The code below works fine if you remove the extern(C). But I
get the error "functionpointertest.d(6): Error: basic type
expected, not extern" with the code as it is.
How do I use alias with extern ?
[...]
alias Callback= extern(C) void function(int);
Compiles as is with dmd
On Thursday, 30 October 2014 at 18:43:21 UTC, Laeeth Isharc wrote:
The code below works fine if you remove the extern(C). But I
get the error "functionpointertest.d(6): Error: basic type
expected, not extern" with the code as it is.
How do I use alias with extern ?
[...]
alia
Hi.
I am trying to translate the following from the Dart header:
typedef void (*Dart_MessageNotifyCallback)(Dart_Isolate
dest_isolate);
So I made a little simple test to understand callbacks in D. The
code below works fine if you remove the extern(C). But I get the
error
On Thursday, 16 October 2014 at 07:55:24 UTC, Mike Parker wrote:
On 10/16/2014 4:54 PM, Mike Parker wrote:
On 10/16/2014 12:18 PM, dysmondad wrote:
Since I've added this call, my program will sometimes but not
always
either generate a core dump or a seg fault. It seems that the
issue is
with
On 10/16/2014 4:54 PM, Mike Parker wrote:
On 10/16/2014 12:18 PM, dysmondad wrote:
Since I've added this call, my program will sometimes but not always
either generate a core dump or a seg fault. It seems that the issue is
with the const char * parameter.
I don't have a good grasp of the differ
On 10/16/2014 12:18 PM, dysmondad wrote:
Since I've added this call, my program will sometimes but not always
either generate a core dump or a seg fault. It seems that the issue is
with the const char * parameter.
I don't have a good grasp of the difference between the way D and C work
for char
ween the way D and C work
> for char * types. The call to loadTexture uses a literal for the file
> name, i.e. "resources/ball.png".
>
> // d lang bindings for C function
> alias void SDL_Renderer;
> alias void SDL_Texture;
> extern (C) SDL_Texture * IMG_LoadTexture
xture uses a literal
for the file name, i.e. "resources/ball.png".
// d lang bindings for C function
alias void SDL_Renderer;
alias void SDL_Texture;
extern (C) SDL_Texture * IMG_LoadTexture(SDL_Renderer * renderer,
const char * file);
// d lang call to extern (C) function
SDL_
Is there way to declare a extern(C) function inside a function without
altering the mangled name?
Should I write a mixin for that based on pragma(mangleof) (used as
extern_C_global_scope in example below) ? Or did someone already implement
that?
extern(C) void foo1();
void fun(){
extern(C) void
On 2014-08-15 6:12 AM, Rémy Mouëza wrote:
assignments of anonymous/inline ones. You may want to add a layer of
abstraction to the API you expose in D so that user D delegates are used
from a second extern (C) delegate itself used by the C++ wrapper:
Thanks for the detailed answer, this is the
otice -- althought it hasn't changed in many years):
/* === */
/// ddg.d
import std.stdio;
import std.string;
/// A C++ function that will take a D delegate.
extern (C) void callDg (immutable(char)* delegate (int, int));
/// A dummy clas
On Friday, 15 August 2014 at 03:10:43 UTC, Etienne Cimon wrote:
I'm looking into making a binding for the C++ API called Botan,
and the constructors in it take a std::function. I'm wondering
if there's a D equivalent for this binding to work out, or if I
have to make a C++ wrapper as well?
Th
I'm looking into making a binding for the C++ API called Botan, and the
constructors in it take a std::function. I'm wondering if there's a D
equivalent for this binding to work out, or if I have to make a C++
wrapper as well?
On Wednesday, 6 August 2014 at 06:50:59 UTC, Alexandr Druzhinin
wrote:
This dlang.org/cpp_interface.html says I can do the following
// c++
namespace N {
void someCppFunction();
}
// d
extern (C++, N) void someCppFunction();
but this http://dpaste.dzfl.pl/e2242263e1dc says I can'
06.08.2014 10:54, Dicebot пишет:
On Wednesday, 6 August 2014 at 06:50:59 UTC, Alexandr Druzhinin wrote:
This dlang.org/cpp_interface.html says I can do the following
// c++
namespace N {
void someCppFunction();
}
// d
extern (C++, N) void someCppFunction();
but this http://dpaste.dzfl.pl
This dlang.org/cpp_interface.html says I can do the following
// c++
namespace N {
void someCppFunction();
}
// d
extern (C++, N) void someCppFunction();
but this http://dpaste.dzfl.pl/e2242263e1dc says I can't
Is this feature implemented?
On Wednesday, 6 August 2014 at 06:50:59 UTC, Alexandr Druzhinin
wrote:
This dlang.org/cpp_interface.html says I can do the following
// c++
namespace N {
void someCppFunction();
}
// d
extern (C++, N) void someCppFunction();
but this http://dpaste.dzfl.pl/e2242263e1dc says I can'
I use a library written in C. There are these two functions
1. MyLib_Initialize(), an existing 3rd party function
2. my_lib_initialize(), my custom function
On Linux (my main platform) it compiled and worked without an
error. On Windows, however, implib printed a warning and said
that two defi
On Thursday, 27 March 2014 at 00:46:33 UTC, Etienne wrote:
Hi,
I'm trying to send a delegate to a modified version of
druntime's GC as follows:
struct GC {
static void onCollect(void* dg)
{
gc_onCollect(cast(void*)dg);
}
There isn't enough information
Hi,
I'm trying to send a delegate to a modified version of druntime's GC as
follows:
struct GC {
static void onCollect(void* dg)
{
gc_onCollect(cast(void*)dg);
}
...
my code:
extern (C) extern __gshared void collecting(void* p,
Am Wed, 22 Jan 2014 17:52:03 +
schrieb "bearophile" :
> Marco Leise:
>
> > Can I define them somehow? The use case is defining extern C
> > functions that contain code to load the real thing from a
> > library.
> >
> > nothrow extern(C) void
Am Wed, 22 Jan 2014 17:52:03 +
schrieb "bearophile" :
> Marco Leise:
>
> > Can I define them somehow? The use case is defining extern C
> > functions that contain code to load the real thing from a
> > library.
> >
> > nothrow extern(C) void
Marco Leise:
Can I define them somehow? The use case is defining extern C
functions that contain code to load the real thing from a
library.
nothrow extern(C) void function(int) someFunc = ???
Perhaps you want:
extern(C) nothrow void someFunc(int someArg);
Bye,
bearophile
Can I define them somehow? The use case is defining extern C
functions that contain code to load the real thing from a
library.
nothrow extern(C) void function(int) someFunc = ???
--
Marco
On 2013-12-28 22:47, Jeremy DeHaan wrote:
Since the C functions can't access anything from D code save for what is
passed through as parameters, can it be called pure? And if so, does the
compiler know how to distinguish C and D in this instance and make it
inherently pure? Does purity do anythi
On Monday, 6 January 2014 at 09:27:26 UTC, Jacob Carlborg wrote:
To be able to load symbols from libraries at runtime they have
to be
declared with extern.
"export", not "extern".
Yeah typo sry.
On 2014-01-05 22:15, TheFlyingFiddle wrote:
Export is currently somewhat broken see DIP45 for an indepth explanation
(link)
To be able to load symbols from libraries at runtime they have to be
declared with extern.
"export", not "extern".
This rule does not hold on linux though since it
sim
o for instance:
void foo() { ... } //This will NOT be avalible for loading under
windows.
export void foo() { ... } //This is avalible for loading under
windows.
extern(C) void foo() { ... } //This will also not be avalible for
loading.
extern is a whole diffrent creature. extern deals with
On Sunday, 5 January 2014 at 19:55:50 UTC, Mineko wrote:
On Sunday, 5 January 2014 at 19:47:46 UTC, FreeSlave wrote:
Some code snippets of what you try to do would help.
Maybe this example explain you something:
//mod.d
extern(C) int foo = 42;
void changeFoo(int val)
{
foo = val
On Sunday, 5 January 2014 at 19:47:46 UTC, FreeSlave wrote:
Some code snippets of what you try to do would help.
Maybe this example explain you something:
//mod.d
extern(C) int foo = 42;
void changeFoo(int val)
{
foo = val;
}
//main.d
import std.stdio;
import mod;
int main
On Sunday, 5 January 2014 at 18:22:54 UTC, Mineko wrote:
I keep getting mixed results searching for this. :\
Just as the title says, is it safe to extern (C) variables?
Something like this:
extern (C) auto foo = 800;
And then call that from another program?
Also, just because this has been
On Sunday, 5 January 2014 at 19:08:44 UTC, Jeremy DeHaan wrote:
On Sunday, 5 January 2014 at 18:22:54 UTC, Mineko wrote:
I keep getting mixed results searching for this. :\
Just as the title says, is it safe to extern (C) variables?
Something like this:
extern (C) auto foo = 800;
And then
On Sunday, 5 January 2014 at 18:22:54 UTC, Mineko wrote:
I keep getting mixed results searching for this. :\
Just as the title says, is it safe to extern (C) variables?
Something like this:
extern (C) auto foo = 800;
And then call that from another program?
Also, just because this has been
I keep getting mixed results searching for this. :\
Just as the title says, is it safe to extern (C) variables?
Something like this:
extern (C) auto foo = 800;
And then call that from another program?
Also, just because this has been bugging me for a while.. Is
export broken, or it it not
On Sunday, 29 December 2013 at 14:50:52 UTC, H. S. Teoh wrote:
Yes, since C code will not throw D exceptions (C doesn't know
anything
about D exceptions). Unless you pass in a function pointer to a
D
function that does throw an exception... but that case doesn't
work for
other reasons, so it ge
On Sat, Dec 28, 2013 at 09:57:06PM +, ponce wrote:
[...]
> >I noticed that in Deimos and Derelict that most(if not all) C
> >function declarations are marked as nothrow. What are the
> >speed/safety benefits of including this?
>
> No speed or safety benefit, but it allows to call these C funct
ently nothrow?
No.
C's name mangling doesn't allow function overloading, but as
far as I know you can overload extern(C) functions in D. Does
adding final help with speed improvements in the D side of
things if added to an extern(C) function declaration?
No.
I was thinking of adding some keywords like final, pure, and
nothrow in to my library to improve various things where
improvements could be made. As I was thinking about this, I
wondered about my extern(C) function declarations and how
keywords could improve those as well.
Since the C
// This calls the D delegate from C.
// One has to pass dg.ctx as first argument.
printf ("result: %s\n", dg.fn (dg.ctx, 42, 7));
}
}
}
in D (ddg.d) {
import std.stdio;
import std.string;
import std.conv;
extern (C) void callDg (
I'd like to expose my D API to C code.
For that, i'm going to write templates generate extern(C)
definition alongside of D-one.
One thing i could do, is to generate D struct that mimics
delegate with appropriate arguments. However, i'm curious of
another possibility:
How do
I'd forgotten about:
int_least8_t
I guess that's what I should use.
On 09/26/2013 03:06 PM, bearophile wrote:
Charles Hixson:
So... if C returns an int64_t and I declare it as an int32_t, will
this cause problems? What about if C returns an int32_t and I
declare it as an int64_t?
201 - 300 of 330 matches
Mail list logo
