On 8/23/17 10:00 AM, Walter Bright wrote:
On 8/23/2017 6:28 AM, Moritz Maxeiner wrote:
Interesting article, though one thing that I'm confused by is
Hence D libraries remain inaccessible to C programs, and chimera
programs (a mix of C and D) are not practical. One cannot
pragmatically “try out” D by add D modules to an existing C program.
I've been mixing C and full D for a while now (on Linux) by either
having the main C program call rt_init/rt_term directly (if druntime
is linked in when building a mixed C/D application), or have
Runtime.initialize/Runtime.terminate be called from D via some
plugin_load/plugin_unload functionality when using D shared libraries.
Why is this not considered practical?
Because in order to add a D function as trivial as:
int foo() { return 3; }
to a C program, now the C program has to link to druntime, and the
program no longer has a small footprint. One of the reasons people use C
is to get that small footprint. This has been a large barrier to C
programs making use of D.
Nope.
Stevens-MacBook-Pro:testd steves$ cat testdfunc.d
extern(C) int foo() { return 3; }
Stevens-MacBook-Pro:testd steves$ cat testdfunc_c.c
#include <stdio.h>
extern int foo();
int main()
{
printf("%d\n", foo());
}
Stevens-MacBook-Pro:testd steves$ dmd -c testdfunc.d
Stevens-MacBook-Pro:testd steves$ gcc -o testdfunc testdfunc_c.c testdfunc.o
Stevens-MacBook-Pro:testd steves$ ./testdfunc
3
It's only if you do something that needs the runtime, such as static
ctors, or use the GC.
-Steve
