On 2015-09-13 12:10, Jakob Ovrum wrote:
On Linux and other ELF-using platforms, initialization and
deinitialization functions could be placed in the .init and .deinit
special sections, but I don't know if druntime has any convenient
provisions for this. With GDC and LDC you can probably use a pr
On Sunday, 13 September 2015 at 10:10:32 UTC, Jakob Ovrum wrote:
On Thursday, 10 September 2015 at 18:01:10 UTC, Russel Winder
wrote:
Is there an easy way of knowing when you do not have to
initialize the D runtime system to call D code from, in this
case, Python via a C adapter?
I naïvely tr
On Thursday, 10 September 2015 at 18:01:10 UTC, Russel Winder
wrote:
Is there an easy way of knowing when you do not have to
initialize the D runtime system to call D code from, in this
case, Python via a C adapter?
I naïvely transformed some C++ to D, without consideration of D
runtime syste
On Saturday, 12 September 2015 at 18:20:37 UTC, Brad Roberts
wrote:
You can get away with it in some circumstances, but it's at
your own risk.
Yeah, I agree.
On 9/12/15 9:20 AM, Adam D. Ruppe via Digitalmars-d-learn wrote:
On Saturday, 12 September 2015 at 09:47:55 UTC, Jacob Carlborg wrote:
Well, if your D function doesn't use anything of the runtime I guess it's not
necessary.
Right. If you don't call into the threading system in the druntime, y
On Saturday, 12 September 2015 at 09:47:55 UTC, Jacob Carlborg
wrote:
Well, if your D function doesn't use anything of the runtime I
guess it's not necessary.
Right. If you don't call into the threading system in the
druntime, you should be ok. Keep in mind though that the GC uses
the threads
On 2015-09-12 10:56, Russel Winder via Digitalmars-d-learn wrote:
I have a small D function (C linkage) compiled to a shared object that
I am calling from Python via CFFI that works fine with no D runtime
initialization. Thus I have experimental evidence "always" is not
entirely the case! I real
On Fri, 2015-09-11 at 21:50 +0200, Jacob Carlborg via Digitalmars-d
-learn wrote:
> On 2015-09-10 20:01, Russel Winder via Digitalmars-d-learn wrote:
> > Is there an easy way of knowing when you do not have to initialize
> > the
> > D runtime system to call D code from, in this case, Python via a C
On 2015-09-10 20:01, Russel Winder via Digitalmars-d-learn wrote:
Is there an easy way of knowing when you do not have to initialize the
D runtime system to call D code from, in this case, Python via a C
adapter?
You always need to initialize the D runtime, unless you have a D main
function. Y
On 2013-11-24 08:22, evilrat wrote:
ok i find out what's your problem. here is 2 ways of solving this problem.
1) build like you do already but add to gcc call phobos lib, so it will
looks like "gcc bar.c foo.o /usr/share/dmd/lib/libphobos2.a"
2) build with foo.d with "dmd foo.d -lib" which ge
On Sunday, 24 November 2013 at 07:22:37 UTC, evilrat wrote:
On Sunday, 24 November 2013 at 05:25:36 UTC, CJS wrote:
dmd -c foo.d
gcc bar.c foo.o
ok i find out what's your problem. here is 2 ways of solving
this problem.
1) build like you do already but add to gcc call phobos lib, so
it wi
On Sunday, 24 November 2013 at 06:48:50 UTC, Jesse Phillips wrote:
On Sunday, 24 November 2013 at 05:54:44 UTC, evilrat wrote:
On Sunday, 24 November 2013 at 05:25:36 UTC, CJS wrote:
bash calls:
dmd -c foo.d
gcc bar.c foo.o
this is wrong. there should flag for building static lib which
sho
On Sunday, 24 November 2013 at 05:25:36 UTC, CJS wrote:
dmd -c foo.d
gcc bar.c foo.o
ok i find out what's your problem. here is 2 ways of solving this
problem.
1) build like you do already but add to gcc call phobos lib, so
it will looks like "gcc bar.c foo.o
/usr/share/dmd/lib/libphobos2
On Sunday, 24 November 2013 at 05:54:44 UTC, evilrat wrote:
On Sunday, 24 November 2013 at 05:25:36 UTC, CJS wrote:
bash calls:
dmd -c foo.d
gcc bar.c foo.o
this is wrong. there should flag for building static lib which
should produce foo.a which then you link with C build.
There isn't an
On Sunday, 24 November 2013 at 05:25:36 UTC, CJS wrote:
bash calls:
dmd -c foo.d
gcc bar.c foo.o
this is wrong. there should flag for building static lib which
should produce foo.a which then you link with C build.
On 2011-07-19 12:39, Loopback wrote:
On 2011-07-19 05:46, Johann MacDonagh wrote:
What is the best method to accomplish this, and are there any
limitations with this method (do I have to allocate the class with
malloc instead etc.)?
Your C++ class "Base" is not compatible with your D "Foo" cl
On 2011-07-19 05:46, Johann MacDonagh wrote:
What is the best method to accomplish this, and are there any
limitations with this method (do I have to allocate the class with
malloc instead etc.)?
Your C++ class "Base" is not compatible with your D "Foo" class. The
v-tables are not guaranteed t
On 7/18/2011 11:52 PM, Andrej Mitrovic wrote:
See I tried using dumpbin, but apparently I wiped it from my PATH so I
had to rely on DLL Export viewer (because I'm lazy and it had an icon
on my desktop!) which doesn't even show this. I had a hunch that was
happening behind the scenes. Thanks for t
Uhh, I tried using ASM to simulate the thiscall calling convention, it
didn't go all to well. :) A wrapper C++ DLL that exposes a C interface
was my workaround.
Here's a page that talks about some problems with passing objects via DLLs:
http://www.prowiki.org/wiki4d/wiki.cgi?BestPractices/DLL
On 7/19/11, Johann MacDonagh wrote:
> If you export it like this, it will be exported as the C++ mangled name.
> If you have extern(C) it will be cdecl "_SetInt" and extern(Windows)
> will be stdcall "_SetInt@4".
Right, that's all pretty standard stuff. :)
>
>> I don't know why, but if you use a
On 7/18/2011 11:27 PM, Loopback wrote:
On 2011-07-19 04:40, Andrej Mitrovic wrote:
You have several problems.
extern(C++) only specifies the calling convention, not the visibility
of the symbol. To export the symbol, list it in a .def file or mark
the function with export in the module itself,
On 2011-07-19 04:40, Andrej Mitrovic wrote:
You have several problems.
extern(C++) only specifies the calling convention, not the visibility
of the symbol. To export the symbol, list it in a .def file or mark
the function with export in the module itself, ala:
export extern(C++) void SetInt(int
On 7/18/2011 10:40 PM, Andrej Mitrovic wrote:
You have several problems.
extern(C++) only specifies the calling convention, not the visibility
of the symbol. To export the symbol, list it in a .def file or mark
the function with export in the module itself, ala:
export extern(C++) void SetInt(i
You have several problems.
extern(C++) only specifies the calling convention, not the visibility
of the symbol. To export the symbol, list it in a .def file or mark
the function with export in the module itself, ala:
export extern(C++) void SetInt(int * foo) {}
I don't know why, but if you use a
On 2011-07-19 00:56, Johann MacDonagh wrote:
On 7/18/2011 5:04 PM, Andrej Mitrovic wrote:
On 7/18/11, Loopback wrote:
On 2011-07-18 21:59, Andrej Mitrovic wrote:
import core.dll_helper; is outdated, use import core.sys.windows.dll;
And also import core.runtime;
Are there any examples coverin
On 7/18/2011 7:08 PM, Andrej Mitrovic wrote:
On 7/19/11, Johann MacDonagh wrote:
FWIW I was able to compile and link a D DLL with the code I copy pasted
in the other message.
Maybe you're running 2.052. I think in 2.053 dll_helper disappeared,
and so in 2.054:
D:\dev\code\d_code\DLLTest>dmd
On 7/19/11, Johann MacDonagh wrote:
> FWIW I was able to compile and link a D DLL with the code I copy pasted
> in the other message.
Maybe you're running 2.052. I think in 2.053 dll_helper disappeared,
and so in 2.054:
D:\dev\code\d_code\DLLTest>dmd mydll.d
mydll.d(9): Error: module dll_helper
On 7/18/2011 5:04 PM, Andrej Mitrovic wrote:
On 7/18/11, Loopback wrote:
On 2011-07-18 21:59, Andrej Mitrovic wrote:
import core.dll_helper; is outdated, use import core.sys.windows.dll;
And also import core.runtime;
Are there any examples covering these new modules, or are the procedure
the
On 7/18/11, Loopback wrote:
> On 2011-07-18 21:59, Andrej Mitrovic wrote:
>> import core.dll_helper; is outdated, use import core.sys.windows.dll;
>> And also import core.runtime;
>
> Are there any examples covering these new modules, or are the procedure
> the same?
>
It's all pretty much the sa
On 2011-07-18 21:59, Andrej Mitrovic wrote:
import core.dll_helper; is outdated, use import core.sys.windows.dll;
And also import core.runtime;
Are there any examples covering these new modules, or are the procedure
the same?
import core.dll_helper; is outdated, use import core.sys.windows.dll;
And also import core.runtime;
On 2011-07-17 22:51, Johann MacDonagh wrote:
On 7/17/2011 3:53 PM, Loopback wrote:
On 2011-07-17 21:45, Loopback wrote:
Hello!
As of my understanding you can write usable c libraries in D by using
extern(C). The problem is that I haven't found any other threads asking
the same question about C
On 7/17/2011 3:53 PM, Loopback wrote:
On 2011-07-17 21:45, Loopback wrote:
Hello!
As of my understanding you can write usable c libraries in D by using
extern(C). The problem is that I haven't found any other threads asking
the same question about C++ (since extern for c++ exists as well). So
I
On 2011-07-17 21:45, Loopback wrote:
Hello!
As of my understanding you can write usable c libraries in D by using
extern(C). The problem is that I haven't found any other threads asking
the same question about C++ (since extern for c++ exists as well). So
I have two questions, is it possible to
34 matches
Mail list logo
