On Friday, 19 February 2021 at 10:21:29 UTC, Max Haughton wrote:
On Friday, 19 February 2021 at 10:18:28 UTC, Preetpal wrote:
On Friday, 19 February 2021 at 10:01:36 UTC, Max Haughton
wrote:
On Friday, 19 February 2021 at 09:44:15 UTC, Preetpal wrote:
[...]
C++ interop is used every day. The
On Friday, 19 February 2021 at 10:18:28 UTC, Preetpal wrote:
On Friday, 19 February 2021 at 10:01:36 UTC, Max Haughton wrote:
On Friday, 19 February 2021 at 09:44:15 UTC, Preetpal wrote:
I want to reuse existing C++ code in a new project that I am
writing in D and I want to use D in an existing
On Friday, 19 February 2021 at 10:01:36 UTC, Max Haughton wrote:
On Friday, 19 February 2021 at 09:44:15 UTC, Preetpal wrote:
I want to reuse existing C++ code in a new project that I am
writing in D and I want to use D in an existing C++ code base
(it is not large). I do not anticipate interop
On Friday, 19 February 2021 at 09:44:15 UTC, Preetpal wrote:
I want to reuse existing C++ code in a new project that I am
writing in D and I want to use D in an existing C++ code base
(it is not large). I do not anticipate interop being an issue.
[...]
C++ interop is used every day. The LLVM
I want to reuse existing C++ code in a new project that I am
writing in D and I want to use D in an existing C++ code base (it
is not large). I do not anticipate interop being an issue.
I am wondering if mixing D and C++ is a common practice? If it is
a common practice, is anyone is currently
On Tuesday, 6 March 2018 at 18:41:15 UTC, H. S. Teoh wrote:
The fix itself may be straightforward, but how to do it without
breaking tons of existing code and provoking user backlash is
the tricky part.
[snip]
Ah, I see what you're saying. People may be depending on the
extra accuracy for
On Tue, Mar 06, 2018 at 06:05:59PM +, jmh530 via Digitalmars-d-learn wrote:
> On Tuesday, 6 March 2018 at 17:51:54 UTC, H. S. Teoh wrote:
> > [snip]
> >
> > I'm not advocating for getting *rid* of 80-bit float support, but
> > only to make it *optional* rather than the default, as currently
>
On Tuesday, 6 March 2018 at 17:51:54 UTC, H. S. Teoh wrote:
[snip]
I'm not advocating for getting *rid* of 80-bit float support,
but only to make it *optional* rather than the default, as
currently done in std.math.
T
Aren't there two issues: 1) std.math functions that cast to real
to pe
On Tue, Mar 06, 2018 at 08:12:57AM +0100, Robert M. Münch via
Digitalmars-d-learn wrote:
> On 2018-03-05 20:11:06 +, H. S. Teoh said:
>
> > Walter has been adamant that we should always compute std.math.*
> > functions with the `real` type, which on x86 maps to the non-IEEE
> > 80-bit floats.
On Tuesday, 6 March 2018 at 08:20:05 UTC, J-S Caux wrote:
On Tuesday, 6 March 2018 at 07:12:57 UTC, Robert M. Münch wrote:
On 2018-03-05 20:11:06 +, H. S. Teoh said:
[snip]
Now, with Uknown's trick of using the C math functions, I can
reconsider. It's a bit of a "patch" but at least it wor
On Tuesday, 6 March 2018 at 07:12:57 UTC, Robert M. Münch wrote:
On 2018-03-05 20:11:06 +, H. S. Teoh said:
Walter has been adamant that we should always compute
std.math.*
functions with the `real` type, which on x86 maps to the
non-IEEE 80-bit
floats. However, 80-bit floats have been de
On Monday, 5 March 2018 at 20:11:06 UTC, H. S. Teoh wrote:
Walter has been adamant that we should always compute
std.math.* functions with the `real` type
T
I don't understand why atan(float) returns real and atan(double)
return real too. If I'm working with float, why does it return a
real?
On 2018-03-05 20:11:06 +, H. S. Teoh said:
Walter has been adamant that we should always compute std.math.*
functions with the `real` type, which on x86 maps to the non-IEEE 80-bit
floats. However, 80-bit floats have been deprecated for a while now,
Hi, do you have a reference for this? I
On Monday, 5 March 2018 at 06:01:27 UTC, J-S Caux wrote:
So the codes are trivial, simply some check of raw speed:
double x = 0.0;
for (int a = 0; a < 10; ++a) x += atan(1.0/(1.0 +
sqrt(1.0 + a)));
for C++ and
double x = 0.0;
for (int a = 0; a < 1_000_000_000; ++a) x += atan
On Monday, 5 March 2018 at 21:05:19 UTC, bachmeier wrote:
I wonder if Ilya has worked on any of this for Mir.
Mir has sin and cos, but that's it. It looks like they use llvm
intrinsics on LDC and then fall back to phobos' implementation.
On Monday, 5 March 2018 at 20:11:06 UTC, H. S. Teoh wrote:
Walter has been adamant that we should always compute
std.math.* functions with the `real` type, which on x86 maps to
the non-IEEE 80-bit floats. However, 80-bit floats have been
deprecated for a while now, and pretty much nobody care
On Mon, Mar 05, 2018 at 06:39:21PM +, J-S Caux via Digitalmars-d-learn
wrote:
[...]
> I've tested these two very basic representative codes:
> https://www.dropbox.com/s/b5o4i8h43qh1saf/test.cc?dl=0
> https://www.dropbox.com/s/zsaikhdoyun3olk/test.d?dl=0
>
> Results:
>
> C++:
> g++ (Apple LLV
On Monday, 5 March 2018 at 18:39:21 UTC, J-S Caux wrote:
But now comes the question: can the D fundamental maths
functions be propped up to be as fast as the C ones?
Probably, if someone takes the time to look at the bottlenecks.
On Monday, 5 March 2018 at 09:48:49 UTC, Uknown wrote:
Depending on your platform, the size of `double` could be
different between C++ and D. Could you check that the size and
precision are indeed the same?
Also, benchmark method is just as important as benchmark code.
Did you use DMD or LDC a
On Monday, 5 March 2018 at 06:01:27 UTC, J-S Caux wrote:
On Monday, 5 March 2018 at 05:40:09 UTC, rikki cattermole wrote:
On 05/03/2018 6:35 PM, J-S Caux wrote:
I'm considering shifting a large existing C++ codebase into D
(it's a scientific code making much use of functions like
atan, log etc
On Monday, 5 March 2018 at 05:35:28 UTC, J-S Caux wrote:
I'm considering shifting a large existing C++ codebase into D
(it's a scientific code making much use of functions like atan,
log etc).
I've compared the raw speed of atan between C++ (Apple LLVM
version 7.3.0 (clang-703.0.29)) and D (d
On Monday, 5 March 2018 at 06:01:27 UTC, J-S Caux wrote:
On Monday, 5 March 2018 at 05:40:09 UTC, rikki cattermole wrote:
On 05/03/2018 6:35 PM, J-S Caux wrote:
I'm considering shifting a large existing C++ codebase into D
(it's a scientific code making much use of functions like
atan, log etc
On Monday, 5 March 2018 at 05:40:09 UTC, rikki cattermole wrote:
atan should work out to only be a few instructions (inline
assembly) from what I've looked at in the source.
Also you should post the code you used for each.
Should be 3-4 instructions. Load input to the FPU (Optional?
Depends
On 05/03/2018 7:01 PM, J-S Caux wrote:
On Monday, 5 March 2018 at 05:40:09 UTC, rikki cattermole wrote:
On 05/03/2018 6:35 PM, J-S Caux wrote:
I'm considering shifting a large existing C++ codebase into D (it's a
scientific code making much use of functions like atan, log etc).
I've compared
On Monday, 5 March 2018 at 05:40:09 UTC, rikki cattermole wrote:
On 05/03/2018 6:35 PM, J-S Caux wrote:
I'm considering shifting a large existing C++ codebase into D
(it's a scientific code making much use of functions like
atan, log etc).
I've compared the raw speed of atan between C++ (Appl
On 05/03/2018 6:35 PM, J-S Caux wrote:
I'm considering shifting a large existing C++ codebase into D (it's a
scientific code making much use of functions like atan, log etc).
I've compared the raw speed of atan between C++ (Apple LLVM version
7.3.0 (clang-703.0.29)) and D (dmd v2.079.0, also l
I'm considering shifting a large existing C++ codebase into D
(it's a scientific code making much use of functions like atan,
log etc).
I've compared the raw speed of atan between C++ (Apple LLVM
version 7.3.0 (clang-703.0.29)) and D (dmd v2.079.0, also ldc2
1.7.0) by doing long loops of such
On Thursday, 10 September 2015 at 12:34:54 UTC, Daniel Kozák
wrote:
On Thu, 10 Sep 2015 11:38:35 +
"Gary Willoughby" wrote:
On Wednesday, 9 September 2015 at 23:22:49 UTC, ponce wrote:
> - RefCounted
>
> Only for D structs. std::shared_ptr works for all.
RefCounted works with classes as
On Thu, 10 Sep 2015 11:38:35 +
"Gary Willoughby" wrote:
> On Wednesday, 9 September 2015 at 23:22:49 UTC, ponce wrote:
> > - RefCounted
> >
> > Only for D structs. std::shared_ptr works for all.
>
> RefCounted works with classes as well.
>
> http://dlang.org/phobos/std_typecons.html#.RefCo
On Wednesday, 9 September 2015 at 23:22:49 UTC, ponce wrote:
- RefCounted
Only for D structs. std::shared_ptr works for all.
RefCounted works with classes as well.
http://dlang.org/phobos/std_typecons.html#.RefCounted
On Wednesday, 9 September 2015 at 20:17:44 UTC, cym13 wrote:
This is subtly missing the main question: isn't C++-like memory
management of D classes possible with Unique, RefCounted and
Scoped?
- Unique
C++ has move semantics which make moves explicit. D's Unique is
more like the deprecat
On Wednesday, 9 September 2015 at 20:37:40 UTC, cym13 wrote:
Hence my question: in what? (I assume you are talking about
Unique RefCounted etc and not about classes).
I think you should just refer them to the relevant man pages.
Explanations are just going to be confusing as they are
differen
On Wednesday, 9 September 2015 at 20:34:03 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 9 September 2015 at 20:17:44 UTC, cym13 wrote:
This is subtly missing the main question: isn't C++-like
memory management of D classes possible with Unique,
RefCounted and Scoped? I understand the limitatio
On Wednesday, 9 September 2015 at 20:17:44 UTC, cym13 wrote:
This is subtly missing the main question: isn't C++-like memory
management of D classes possible with Unique, RefCounted and
Scoped? I understand the limitations you mentioned, but it
I don't think it is a good idea to tell C++ progr
On Wednesday, 9 September 2015 at 20:05:06 UTC, ponce wrote:
C++ only has a D struct equivalent so all destructors are
called deterministically. It's the addition of classes that
create the problems in D.
C++ can also throw by value, something that D can't really do.
C++ objects can be:
- hea
On Wednesday, 9 September 2015 at 19:53:55 UTC, ponce wrote:
Oops, posted by mistake.
On Wednesday, 9 September 2015 at 19:48:00 UTC, cym13 wrote:
Hi,
I know C++ and D without being a C++ or D guru (I know way
more about D though). When talking about memory management the
problem of RAII is
On Wednesday, 9 September 2015 at 19:48:00 UTC, cym13 wrote:
Hi,
I know C++ and D without being a C++ or D guru (I know way more
about D though). When talking about memory management the
problem of RAII is often mentioned along with the fact that
classes use the GC. I know well the difference
Hi,
I know C++ and D without being a C++ or D guru (I know way more
about D though). When talking about memory management the problem
of RAII is often mentioned along with the fact that classes use
the GC. I know well the difference between structs and classes
and don't want to talk about the
On Sun, 10 Aug 2014 19:39:29 +
seany via Digitalmars-d-learn wrote:
> Solved :
> http://stackoverflow.com/questions/25232194/c-and-d-communication/25232265#25232265
almost exactly what i wrote in my first reply. except that i wrote
about using .ptr and size_t for item counter too.
signatur
Solved :
http://stackoverflow.com/questions/25232194/c-and-d-communication/25232265#25232265
of course I read this : http://dlang.org/interfaceToC.html
I have 64 bit OS
So here is the final situtaion
I have a file: software_pluginInterface.di
Here I declare :
extern (C): void performComputation(char lib[], char func[],
void* ptr[], int varNum );
// lib and func will be used later
Then i have the corresponding C file: software_pluginInterface.c,
where I dec
On Sunday, 10 August 2014 at 15:37:41 UTC, seany wrote:
On Sunday, 10 August 2014 at 15:34:30 UTC, ketmar via
Digitalmars-d-learn wrote:
from D side -- yes. just don't store passed pointer on C side,
'cause
it can be changed on array resize.
Excellent,
So if I have
int [] array;
void * pt
On Sunday, 10 August 2014 at 14:26:29 UTC, seany wrote:
In D, arrays are dynamic. However, to the best of my knowledge,
in C, they are static.
I am having difficulty in imagining how to send D arrays to a C
function.
My first Idea was to make a pointer to the array. then find the
size of th
On Sunday, 10 August 2014 at 15:34:30 UTC, ketmar via
Digitalmars-d-learn wrote:
from D side -- yes. just don't store passed pointer on C side,
'cause
it can be changed on array resize.
Excellent,
So if I have
int [] array;
void * ptr_to_array = &array;
/* populate array here */
C_Functi
On Sun, 10 Aug 2014 15:24:29 +
seany via Digitalmars-d-learn wrote:
> Thank you, so the running out of space problem is taken care of
> automatically?
from D side -- yes. just don't store passed pointer on C side, 'cause
it can be changed on array resize.
but if you want to be able to resiz
Thank you, so the running out of space problem is taken care of
automatically?
On Sun, 10 Aug 2014 14:26:27 +
seany via Digitalmars-d-learn wrote:
> I am having difficulty in imagining how to send D arrays to a C
> function.
do something like this:
=== C SIDE ===
void c_array_processing (int *items, size_t item_count) {
// use items pointer as normal C-like array po
In D, arrays are dynamic. However, to the best of my knowledge,
in C, they are static.
I am having difficulty in imagining how to send D arrays to a C
function.
My first Idea was to make a pointer to the array. then find the
size of the array, which itself is an array, therefore take the
po
The actual code is not that much slower according to the numerous
other operations we do. And certainly faster than D version doing
almost nothing.
Well it is about massive bitshifts and array accesses and
calculations.
With all the optimizations we are on par with fortran numerical
code (tha
On Wednesday, 9 July 2014 at 13:18:00 UTC, Larry wrote:
You are definitely right, I did mess up while translating !
I run the corrected codes (the ones I was meant to provide :S)
and on a slow macbook I end up with :
C : 2
D : 15994
Of course when run on very high end machines, this diff is
Measure a larger number of loops. I understand you're concerned
about microseconds, but your benchmark shows nothing because your
timer is simply not accurate enough for this. The benchmark that
bearophile showed where C took ~2 nanoseconds vs the ~7000 D took
heavily implies to me that the C i
Right
On 07/09/2014 12:47 PM, Larry wrote:
> On Wednesday, 9 July 2014 at 18:18:43 UTC, Ali Çehreli wrote:
>> On 07/09/2014 03:57 AM, Larry wrote:
>>
>> > struct timeval s,e;
>> [...]
>> > gettimeofday(&e,NULL);
>> >
>> > printf("so ? %d %lu %d %d %d",g,e.tv_usec - s.tv_usec,
>> > arr[4]
On Wednesday, 9 July 2014 at 18:18:43 UTC, Ali Çehreli wrote:
On 07/09/2014 03:57 AM, Larry wrote:
> struct timeval s,e;
[...]
> gettimeofday(&e,NULL);
>
> printf("so ? %d %lu %d %d %d",g,e.tv_usec - s.tv_usec,
> arr[4],arr[9],pol);
Changing the topic a little, the calculation ab
On 07/09/2014 03:57 AM, Larry wrote:
> struct timeval s,e;
[...]
> gettimeofday(&e,NULL);
>
> printf("so ? %d %lu %d %d %d",g,e.tv_usec - s.tv_usec,
> arr[4],arr[9],pol);
Changing the topic a little, the calculation above ignores the tv_sec
members of s and e.
Ali
@Chris :
Actually yes. If we consider the device to run 20h a day, by
shaving a few microseconds there and there on billions of
operations a day over a whole machine park, you can enable
yourself to shut down some of them for maintenance more easily,
or pause some of them letting their battery
I may definitely help on the D project.
I noticed that gdc doesn't have profile guided optimization too.
So yeah, I cannot use D right now, I mean for this project.
Ok, I will do my best to have some spare time on Dlang. Didn't
really looked at the code already and I code for years in C,
which
On Wednesday, 9 July 2014 at 15:09:09 UTC, Larry wrote:
On Wednesday, 9 July 2014 at 14:30:41 UTC, John Colvin wrote:
On Wednesday, 9 July 2014 at 13:46:59 UTC, Larry wrote:
The rest of the code is numerical so it will not change by
much the fact that d cannot get back the huge launching time.
On Wednesday, 9 July 2014 at 15:09:09 UTC, Larry wrote:
On Wednesday, 9 July 2014 at 14:30:41 UTC, John Colvin wrote:
On Wednesday, 9 July 2014 at 13:46:59 UTC, Larry wrote:
The rest of the code is numerical so it will not change by
much the fact that d cannot get back the huge launching time.
On Wednesday, 9 July 2014 at 14:30:41 UTC, John Colvin wrote:
On Wednesday, 9 July 2014 at 13:46:59 UTC, Larry wrote:
The rest of the code is numerical so it will not change by
much the fact that d cannot get back the huge launching time.
At the microsecond level(even nano) it counts because of
On Wednesday, 9 July 2014 at 14:30:41 UTC, John Colvin wrote:
You say you are worried about microseconds and power
consumption, but you are suggesting launching a new process - a
lot of overhead - to do a small amount of numerical work.
Not much overhead if you don't use a MMU and use static l
On Wednesday, 9 July 2014 at 13:46:59 UTC, Larry wrote:
The rest of the code is numerical so it will not change by much
the fact that d cannot get back the huge launching time. At the
microsecond level(even nano) it counts because of electrical
consumption, size of hardware, heat and so on.
Y
Larry:
@Bearophile: just tried. No dramatic change.
import core.memory;
void main() {
GC.disable;
...
}
That just means disabling the GC, so the start time is the same.
What you want is to not start the GC/runtime, stubbing it out...
(assuming you don't need the GC in your program).
I thi
@Bearophile: just tried. No dramatic change.
import core.memory;
void main() {
GC.disable;
...
}
Larry:
The rest of the code is numerical so it will not change by much
the fact that d cannot get back the huge launching time. At the
microsecond level(even nano) it counts because of electrical
consumption, size of hardware, heat and so on.
Have you benchmarked the D code without starting
On Wednesday, 9 July 2014 at 13:46:59 UTC, Larry wrote:
Yes you are perfectly right but our need is to run the fastest
code on the lowest powered machines. Not servers but embedded
systems.
That is why I just test the overall structures.
The rest of the code is numerical so it will not change
Yes you are perfectly right but our need is to run the fastest
code on the lowest powered machines. Not servers but embedded
systems.
That is why I just test the overall structures.
The rest of the code is numerical so it will not change by much
the fact that d cannot get back the huge launch
On Wednesday, 9 July 2014 at 13:18:00 UTC, Larry wrote:
On Wednesday, 9 July 2014 at 12:25:40 UTC, bearophile wrote:
Larry:
Now the performance :
D : 12 µs
C : < 1µs
Where does the diff comes from ? Is there a way to optimize
the d version ?
Again, I am absolutely new to D and those are my
Larry:
Of course when run on very high end machines, this diff is
almost non existent but we want to run on very low powered
hardware.
Ok, even with a longer code, there will always be a launch
penalty for d. So I cannot use it for very high performance
loops.
If you run it on very low po
On Wednesday, 9 July 2014 at 12:25:40 UTC, bearophile wrote:
Larry:
Now the performance :
D : 12 µs
C : < 1µs
Where does the diff comes from ? Is there a way to optimize
the d version ?
Again, I am absolutely new to D and those are my very first
line of code with it.
Your C code is not e
Larry:
Now the performance :
D : 12 µs
C : < 1µs
Where does the diff comes from ? Is there a way to optimize the
d version ?
Again, I am absolutely new to D and those are my very first
line of code with it.
Your C code is not equivalent to the D code, there are small
differences, even th
On Wednesday, 9 July 2014 at 10:57:33 UTC, Larry wrote:
Hello,
I extracted a part of my code written in c.
it is deliberately useless here but I would understand the
different technics to optimize such kind of code with gdc
compiler.
it currently runs under a microsecond.
Constraint : the w
Hello,
I extracted a part of my code written in c.
it is deliberately useless here but I would understand the
different technics to optimize such kind of code with gdc
compiler.
it currently runs under a microsecond.
Constraint : the way the code is expressed cannot be changed much
we need
On Wednesday, 2 April 2014 at 21:54:58 UTC, FreeSlave wrote:
It's only server. Maybe problem is on client side.
Yes, it is only a server which needs to answer back the client;
And there was the problem: I was not fetching the client's
address, and since UDP is an unconnected protocol, I couldn
It's only server. Maybe problem is on client side.
Try this if you are on Linux:
//Linux C client
#include
#include
#include
#include
#include
#include
#include
int main()
{
int sock, res;
struct sockaddr_in addr;
const char* hello;
size_t len;
sock = socket(AF_INET,
On Wednesday, 2 April 2014 at 08:55:23 UTC, Russel Winder wrote:
The real signature of main in C/C++ is, I believe:
int main(int, char**, char**)
I believe in C it is:
int main(void)
int main(int,char**)
or implementation defined (e.g. the third env pointer in the main
signature fro
On 4/2/14, Dicebot wrote:
> D main != C main, latter is implemented in D runtime to call the
> former. 0 will be also returned by latter, not the former.
Actually, the compiler injects a return statement in D's main.
It generates the actual C main function (unless WinMain/DllMain is
provided), w
On Wednesday, 2 April 2014 at 08:55:23 UTC, Russel Winder wrote:
On Wed, 2014-04-02 at 00:34 +, bearophile wrote:
Alexandre L.:
> int main(string[] args)
> {
If you don't need args, then I suggest to not put it as main
argument. So probably this is better (note no int nor return,
in D
Russel Winder:
what is the real signature in D?
The _real_ signature of main() is flexible, you can use:
void main()
int main(in string[] args) pure nothrow
D allows you to omit the args if you don't need them, returns 0
if you don't it, and it can be pure/nothrow/@safe as desired.
Perh
On Wed, 2014-04-02 at 00:34 +, bearophile wrote:
> Alexandre L.:
> > int main(string[] args)
> > {
>
> If you don't need args, then I suggest to not put it as main
> argument. So probably this is better (note no int nor return, in
> D they are not needed):
>
> void main() {
> ...
> }
I am
My bad; It returns immutable(char)*.
Still won't work with send(); Am I right to supposed the
receiving client must handle a ubyte[] as well (C++) ?
On Wednesday, 2 April 2014 at 00:34:08 UTC, bearophile wrote:
char[] rep = "regan\0".dup;
s.send(cast(ubyte[])rep);
casts are dangerous, because they silently assume you know what
you are doing. As first try I suggest you to remove every
cast()
Alexandre L.:
Some comments on your code:
Here's my 'server' code:
int main(string[] args)
{
If you don't need args, then I suggest to not put it as main
argument. So probably this is better (note no int nor return, in
D they are not needed):
void main() {
...
}
int co
Hello,
I lately did a minimal udp socket server-client application with
C++, and I've been trying to recreate it with D, after.
I'm able to get the client's request (C++ client) without too
much trouble (after I figured I needed to get it in ubyte[]).
Then I've tried to send the client an an
On Monday, 21 October 2013 at 11:29:54 UTC, develop32 wrote:
On Monday, 21 October 2013 at 11:08:15 UTC, qznc wrote:
On Saturday, 19 October 2013 at 13:20:28 UTC, develop32 wrote:
Hi,
Are there any recent improvements in how D interfaces with
C++? I got the impression that some work has been d
On Monday, 21 October 2013 at 11:08:15 UTC, qznc wrote:
On Saturday, 19 October 2013 at 13:20:28 UTC, develop32 wrote:
Hi,
Are there any recent improvements in how D interfaces with
C++? I got the impression that some work has been done on
that, in order to make DMD a self-hosting compiler.
On Saturday, 19 October 2013 at 13:20:28 UTC, develop32 wrote:
Hi,
Are there any recent improvements in how D interfaces with C++?
I got the impression that some work has been done on that, in
order to make DMD a self-hosting compiler.
I do not know of any recent improvements.
The current pl
Hi,
Are there any recent improvements in how D interfaces with C++? I
got the impression that some work has been done on that, in order
to make DMD a self-hosting compiler.
Resolved.
Thanks everyone.
On Tue, Jan 3, 2012, at 04:49 AM, Andrej Mitrovic wrote:
> Maybe I'm wrong, but IIRC objconv won't work on import libs.
>
> But there are other ways to do it: http://support.microsoft.com/kb/131313
>
--
D
On 1/3/2012 12:43 PM, Mike Parker wrote:
On 1/3/2012 10:02 AM, DNewbie wrote:
Thank you both.
I've created a D DLL [http://dlang.org/dll.html], then I've loaded it
from a C program [compiled with dmc].
However, I'd want to be able to call it from a C program compiled with
MSVC, and I got a link
Maybe I'm wrong, but IIRC objconv won't work on import libs.
But there are other ways to do it: http://support.microsoft.com/kb/131313
On 1/3/2012 10:02 AM, DNewbie wrote:
Thank you both.
I've created a D DLL [http://dlang.org/dll.html], then I've loaded it from a C
program [compiled with dmc].
However, I'd want to be able to call it from a C program compiled with MSVC,
and I got a link error - unresolved external symbol [lin
Thank you both.
I've created a D DLL [http://dlang.org/dll.html], then I've loaded it from a C
program [compiled with dmc].
However, I'd want to be able to call it from a C program compiled with MSVC,
and I got a link error - unresolved external symbol [link testdll.obj
/implib:mydll.lib /out:t
Jakob Ovrum Wrote:
> As for loading C symbols in a DLL from a D program, you must link
> against an import library of the DLL, and create an interface
> module (similar to a header file) with the C declarations.
Alternatively, you can load the DLL via the Windows API.
http://msdn.microsoft.com/en
On Saturday, 31 December 2011 at 19:05:44 UTC, DNewbie wrote:
C program loads D dll
or
D program loads C dll
Is it possible?
Both are possible.
Here's how to create a DLL in D, usable from C:
http://dlang.org/dll.html
As for loading C symbols in a DLL from a D program, you must link
against
C program loads D dll
or
D program loads C dll
Is it possible?
--
D
Hello. Randomly bored tonight.
Motivated by this:
http://stackoverflow.com/questions/3540596/mixing-c-and-d-code-in-the-same-program,
I was trying to get c to call d. I can't remember; is it actually possible?
64 bit Fedora and gcc; here's what I have:
$ cat test.d
import std.c.stdio;
ext
98 matches
Mail list logo
