// .d file
import std.stdio;
import std.conv;
import test;
void main() {
writeln("Hello, World!");
pragma(mangle, "printMessage");
extern (C) void printMessage();
printMessage();
}
```
This was fixed by the dear GH Ghost in
https://github.com/dlang/dmd
mport test;
void main() {
writeln("Hello, World!");
extern (C) void printMessage();
printMessage();
}
```
Thanks in advance!
Put `printMessage` outside the main function. Inside the main
function, it has C linkage, but not C name mangling.
-Steve
: undefined symbol: _D4test4mainFZ12printMessageUZv
referenced by test.obj:(_Dmain)
```
```
// .c file
#include
void printMessage() {
printf("Hello from C!\n");
}
```
```
// .d file
import std.stdio;
import std.conv;
import test;
void main() {
writeln("Hello, World!");
On Wednesday, 11 October 2023 at 13:36:16 UTC, Paul wrote:
On Wednesday, 11 October 2023 at 12:54:53 UTC, user1234 wrote:
`extern(C)` on module level functions affect the mangling and
the calling convention.
- Mangling is used by the linker to link symbols between
objects.
- Calling
On Wednesday, 11 October 2023 at 13:36:16 UTC, Paul wrote:
On Wednesday, 11 October 2023 at 12:54:53 UTC, user1234 wrote:
`extern(C)` on module level functions affect the mangling and
the calling convention.
- Mangling is used by the linker to link symbols between
objects.
- Calling
On Wednesday, 11 October 2023 at 12:54:53 UTC, user1234 wrote:
`extern(C)` on module level functions affect the mangling and
the calling convention.
- Mangling is used by the linker to link symbols between
objects.
- Calling convention affects the compiler backend in how code
is generated
On Wednesday, 11 October 2023 at 12:36:58 UTC, Paul wrote:
What does the extern (c) attribute(?) do?
Does it tell the compiler/linker to build the function like a C
compiler would build a C function? If so what does that mean?
Does it tell the compiler/linker to let C functions know it
exists
On Wednesday, 11 October 2023 at 12:36:58 UTC, Paul wrote:
What does the extern (c) attribute(?) do?
Does it tell the compiler/linker to build the function like a C
compiler would build a C function? If so what does that mean?
Does it tell the compiler/linker to let C functions know it
exists
What does the extern (c) attribute(?) do?
Does it tell the compiler/linker to build the function like a C
compiler would build a C function? If so what does that mean?
Does it tell the compiler/linker to let C functions know it
exists? If so what does that mean?
Is it meant for the compiler
On Friday, 14 April 2023 at 17:31:02 UTC, backtrack wrote:
however the memory is not releasing.
With the D GC, your object can have three state:
- reachable by GC. If D code can see the reference, then it's
"alive", kept alive by GC scanning. The GC finds the reference
and doesn't touch
On 4/13/23 20:50, backtrack wrote:
> mystruct* getmystruct()
> {
> mystruct* mystruct = cast(mystruct*)malloc(mystruct.sizeof);
> return mystruct;
>
> }
There must be a corresponding function to do the cleaning:
void freemystruct(mystruct* ptr) {
free ptr;
;
}
```
That won't work because the C++ programm calling the D dynlib
will not have its stack scanned, leading to that object being
reclaimed early.
OP could add another extern(C) D function to free the allocated
object.
Or another extern(C) D function to call GC.addRoot
Thank you for your response
On Friday, 14 April 2023 at 11:15:59 UTC, Guillaume Piolat wrote:
OP could add another extern(C) D function to free the allocated
object.
Or another extern(C) D function to call GC.addRoot
Or simpler, add that object to a list of object in D DLL
__gshared list, then clear the list
(or set
will not have its stack scanned, leading to that object being
reclaimed early.
OP could add another extern(C) D function to free the allocated
object.
Or another extern(C) D function to call GC.addRoot
On Friday, 14 April 2023 at 03:50:37 UTC, backtrack wrote:
Dear All, I am new to D lang. I have been given a task to
consume the .dll generated from a D lang project.
I added extern (c) function for call the .dll from CPP file. i
have code like below
```
// myfile.d
extern(c
Dear All, I am new to D lang. I have been given a task to consume
the .dll generated from a D lang project.
I added extern (c) function for call the .dll from CPP file. i
have code like below
```
// myfile.d
extern(c)
{
mystruct* getmystruct()
{
mystruct* mystruct =
cast
On Wednesday, 12 April 2023 at 21:00:04 UTC, John Chapman wrote:
You can also express it like this:
```d
extern(C) alias FuncPtr = void* function(void*);
```
Thank you! This is how I was planning to do anyway because other
that the fact that I like the syntax of that a little bit more
On Wednesday, 12 April 2023 at 20:36:59 UTC, H. S. Teoh wrote:
IMO this is a bug either in D's syntax or in the parser. I'd
file an enhancement request.
In the meantime, you can use alias as a workaround:
---snip---
extern(C) void* abc(void*) {return null;}
alias FuncPtr = typeof
On Wednesday, 12 April 2023 at 20:36:59 UTC, H. S. Teoh wrote:
---snip---
extern(C) void* abc(void*) {return null;}
alias FuncPtr = typeof();
You can also express it like this:
```d
extern(C) alias FuncPtr = void* function(void*);
```
d; }
> }
>
> ```
>
> Yes, I'm trying to "encapsulate" the Pthread (POSIX threads) API.
> Normally, the function pointer that is passed to "pthread_create" must
> be "extern(C)" and this is the complaining that the compile does. So,
> I'm thinking
(pthread_attr_t*) attr = null) {
pthread_create(_id, attr, func, arg);
}
@property:
pthread_t id() { return this.thread_id; }
}
```
Yes, I'm trying to "encapsulate" the Pthread (POSIX threads) API.
Normally, the function pointer that is passed to "pthread_create"
e variable with extern(C) can indeed solve
it. I had actually tried this, but it was not compiling for
another reason.
The next reason (as you see in the GitHub link) is that the
variable in question is a (constructor) parameter. D can't seem
to compile extern(C) inlined somewhere else.
Indeed alia
On 22.11.22 22:11, XavierAP wrote:
I was surprised when it didn't compile, though I immediately found it
understandable...
Already read through https://dlang.org/spec/interfaceToC.html
and https://wiki.dlang.org/Bind_D_to_C
Is it really the case (that an extern(C) function pointer cannot
containing your callback type.
```d
alias DCallback = extern(C) void function();
DCallback cb;
cb = yourCFunction;
```
I was surprised when it didn't compile, though I immediately
found it understandable...
Already read through https://dlang.org/spec/interfaceToC.html
and https://wiki.dlang.org/Bind_D_to_C
Is it really the case (that an extern(C) function pointer cannot
be assigned to a D variable
On Tuesday, 25 January 2022 at 01:41:03 UTC, Steven Schveighoffer
wrote:
On 1/24/22 8:31 PM, Jaime wrote:
Can I, for instance, safely call Fiber.yield in a C callback
that I know will be run in a Fiber?
I would *imagine* it's fine, all the fiber context switch is
doing (WRT the stack) is
|- Call into a C API (stays on same thread)
> | | |- Extern (C) callback (stays on same thread)
> | | | |- Fiber.yield <-- Is this OK?
I haven't tested this myself, but I *think* it should be OK.
One thing to watch out for, though, is the size of the Fiber's stack
(this can be speci
On 1/24/22 8:31 PM, Jaime wrote:
**The lede**:
Can I, for instance, safely call Fiber.yield in a C callback that I know
will be run in a Fiber?
The stack will look like:
Thread
|- Fiber in D runtime
| |- Call into a C API (stays on same thread)
| | |- Extern (C) callback (stays on same
**The lede**:
Can I, for instance, safely call Fiber.yield in a C callback that
I know will be run in a Fiber?
The stack will look like:
Thread
|- Fiber in D runtime
| |- Call into a C API (stays on same thread)
| | |- Extern (C) callback (stays on same thread)
| | | |- Fiber.yield
On Wednesday, 16 June 2021 at 02:46:36 UTC, cc wrote:
I can't seem to get it to work as a return type, but
interestingly it does work as an out/pass by ref parameter.
Probably for returning the struct it needs some allocation
directive in C# but I'm not sure. Maybe C# also tries something
On Sunday, 13 June 2021 at 21:13:33 UTC, frame wrote:
On Sunday, 13 June 2021 at 10:02:45 UTC, cc wrote:
it seems to work as expected with the same C# code. Does D
explicitly disallow slices as an extern(C) export parameter
type?
The spec says that there is no equivalent to type[]. You get
On Sunday, 13 June 2021 at 10:02:45 UTC, cc wrote:
it seems to work as expected with the same C# code. Does D
explicitly disallow slices as an extern(C) export parameter
type?
The spec says that there is no equivalent to type[]. You get a
type* instead.
t(d.length == s.length);
assert(d.ptr == s.ptr);
```
If I write a DLL export like:
```d
extern(C) export string someDLLFunc() {
return "hello";
}
```
and import it in C# (VS .NET):
```c#
struct DString {
public long length;
public IntPtr ptr;
}
[DllImport("my
On Tuesday, 6 April 2021 at 09:33:32 UTC, cc wrote:
Just encountered this compilation failure in DMD winx64 2.096,
which previously worked in 2.095 and prior versions.
DMD 2.094.2 fails with the same error?
But current master works for me.
Just wondering if it's a bug, or a new issue to keep
.
Given the following 4-file setup:
// main.d
import cream;
void main() {}
// cream/package.d
module cream;
public import cream.dcream;
public import cream.callbacks;
// cream/callbacks.d
module cream.callbacks;
import cream;
extern(C++) class CallbackBase {}
// cream/dcream.d
module
On Wednesday, 13 January 2021 at 15:11:40 UTC, Dennis wrote:
On Wednesday, 13 January 2021 at 14:04:52 UTC, dog2002 wrote:
[...]
I don't think this is part of the standard library.
Here's a piece of code I wrote a while ago if that's useful:
[...]
Thank you so much!
On Wednesday, 13 January 2021 at 14:04:52 UTC, dog2002 wrote:
I could use extern(c) and Process Walking (Process32First,
Process32Next), but maybe there is a way to get the list by
means of D?
I don't think this is part of the standard library.
Here's a piece of code I wrote a while ago
I need to get a list of processes in Windows (and their pid). I
could use extern(c) and Process Walking (Process32First,
Process32Next), but maybe there is a way to get the list by means
of D?
On 2020-12-16 16:18, Dave P. wrote:
Is this a bug in the spec or in the implementation?
Yeah, that's a good question. That's always problematic with D. The spec
is incomplete.
How do we get this fixed?
The simplest would be to change the spec.
--
/Jacob Carlborg
On Wednesday, 16 December 2020 at 06:46:42 UTC, Jacob Carlborg
wrote:
On Wednesday, 16 December 2020 at 04:17:13 UTC, Mike Parker
wrote:
However, the D calling convention is defined to be identical
to the C calling convention on the host system for everything
except Windows x86.
That's
On Wednesday, 16 December 2020 at 04:17:13 UTC, Mike Parker wrote:
So what you're asking for is a way to retain the D name
mangling on an extern C function. The way to do that is with
`pragma(mangle, "new_name")`. To match the original D function
mangling, declare the function fir
On Wednesday, 16 December 2020 at 04:17:13 UTC, Mike Parker wrote:
However, the D calling convention is defined to be identical to
the C calling convention on the host system for everything
except Windows x86.
Also keep in mind that D supports other types than C does, like D
arrays and
On Wednesday, 16 December 2020 at 04:17:13 UTC, Mike Parker wrote:
However, the D calling convention is defined to be identical to
the C calling convention on the host system for everything
except Windows x86.
That's what's specified, but that's not how DMD actually behaves.
DMD passes the
On Wednesday, 16 December 2020 at 04:45:34 UTC, Dave P. wrote:
Oh interesting, so I only need extern(C) for declaring symbols
I’m linking to and
for symbols I want to export to C. I had sort of assumed that D
might have
different calling conventions for different things, but that
makes
function pointers in D and C without
any name whatsoever.
What matters is that both sides agree on the number and type of
parameters accepted by the function that's pointed to, and that
they both agree on the calling convention. I don't believe
extern(C) has any effect on templated functions
On 12/15/20 2:04 PM, Dave P. wrote:
> I want to pass
> some templated functions as function pointers to some C code
As Mike Parker said, it works:
// The same thing as a C function pointer:
alias Func = long function(int);
long bar(T)(int) {
return 0;
}
Func f0 = &(bar!float);
Func d1 =
On Tuesday, 15 December 2020 at 22:04:12 UTC, Dave P. wrote:
I can’t find this in the spec, but from experimentation it
seems like extern(C) only affects name mangling of functions at
the top level scope. Thus extern(C) function templates would be
mangled differently, but still use the C
I can’t find this in the spec, but from experimentation it seems
like extern(C) only affects name mangling of functions at the top
level scope. Thus extern(C) function templates would be mangled
differently, but still use the C calling convention. Is this
right? I want to pass some templated
I know the problem that TypeInfo != TypeInfo in main and library
context. Is there are a hack to get the data from the Variant
even if the TypeInfo-check fails?
I assume the only workaround is using an own struct or serializer
to achieve the same functionality?
On 10/16/20 4:12 PM, WhatMeWorry wrote:
> Isn't dlopen() for Linux
More like dlopen() is for Posix, which means it should be available on
Windows as well.
However, as I've discovered, a D shared library cannot be loaded with
dlopen() because the main program and the shared library would do
On Friday, 16 October 2020 at 15:14:03 UTC, Ali Çehreli wrote:
On 10/15/20 2:42 PM, Ali Çehreli wrote:
> I've recently done the same by calling dlopen() and dlsym()
> directly. Runtime.loadLibrary documentation says "If the
library
> contains a D runtime it will be integrated with the current
On 10/15/20 2:42 PM, Ali Çehreli wrote:
> I've recently done the same by calling dlopen() and dlsym()
> directly. Runtime.loadLibrary documentation says "If the library
> contains a D runtime it will be integrated with the current runtime."
> That would explain why my program seg-faults for my
On Thu, Oct 15, 2020 at 09:47:16PM +, IGotD- via Digitalmars-d-learn wrote:
> On Thursday, 15 October 2020 at 21:29:59 UTC, WhatMeWorry wrote:
> >
> > I've go a small DLL and a test module both written in D. Why do I
> > need to use the extern(C)? Shouldn't both
On Thursday, 15 October 2020 at 21:29:59 UTC, WhatMeWorry wrote:
I've go a small DLL and a test module both written in D. Why do
I need to use the extern(C)? Shouldn't both sides be using D
name wrangling?
You have answered your own question. If you're not using
extern(C), D just like C
On 10/15/20 2:29 PM, WhatMeWorry wrote:
> name wrangling?
Name mangling. :) I don't know the answer but I can hijack your thread.
> import core.runtime;
> auto mydll = Runtime.loadLibrary("mydll.dll");
Interesting. I've recently done the same by calling dlopen() and dlsym()
I've go a small DLL and a test module both written in D. Why do I
need to use the extern(C)? Shouldn't both sides be using D name
wrangling?
mydll.d
module mydll;
extern(C): // removing or changing to (D): results in error
export
On Wednesday, 14 October 2020 at 00:25:56 UTC, Jamie wrote:
Happy to file a bug, but if it was a bug in the mangler
wouldn't both C++ and D get the same result? Assuming D uses
the same mangler for the extern(C++) stuff.
Bug in the D frontend implementation of Itanium C++ mangling.
https
On Tuesday, 13 October 2020 at 23:39:38 UTC, Ali Çehreli wrote:
On 10/13/20 4:11 PM, James Blachly wrote:
On 10/13/20 5:23 AM, Jamie wrote:
I think the issue is with D's "turtles all the way down" style
const. My workaround would be to define wrapper functions that
may need to do casting on
both C++ and D get the same result? Assuming D uses the same
mangler for the extern(C++) stuff.
On Tuesday, 13 October 2020 at 09:23:48 UTC, Jamie wrote:
It appears that func3 and func4 take on different types
depending on other variables being present? Is this expected?
Nope, it's a bug in the Itanium C++ mangler, please file a bug.
MSVC++ mangling seems fine, after fixing the D
On 10/13/20 4:11 PM, James Blachly wrote:
On 10/13/20 5:23 AM, Jamie wrote:
Building with:
g++ -c a.cpp
dmd main.d a.o
Throws the error:
/usr/bin/ld: main.o: in function `_Dmain':
main.d:(.text._Dmain[_Dmain]+0x31): undefined reference to `void
func3(int*, int*)'
/usr/bin/ld:
On 10/13/20 5:23 AM, Jamie wrote:
Building with:
g++ -c a.cpp
dmd main.d a.o
Throws the error:
/usr/bin/ld: main.o: in function `_Dmain':
main.d:(.text._Dmain[_Dmain]+0x31): undefined reference to `void
func3(int*, int*)'
/usr/bin/ld: main.d:(.text._Dmain[_Dmain]+0x3e): undefined reference to
I'm having difficulties linking templated functions with multiple
pointer arguments with extern(C++).
a.cpp
-
template void func1(T *b){}
template void func1(int *b);
template void func2(const T *a){}
template void func2(const int *a);
template void func3(T *b, const T *a){}
template void
On Monday, 14 September 2020 at 18:58:44 UTC, 60rntogo wrote:
On Monday, 14 September 2020 at 17:11:59 UTC, k2aj wrote:
AFAIK the only way to have default ref arguments is to use a
global variable:
---
extern(C++) struct Foo
{
int x;
}
immutable foo1 = Foo(1);
extern(C++) void fun(const ref
On Monday, 14 September 2020 at 17:11:59 UTC, k2aj wrote:
AFAIK the only way to have default ref arguments is to use a
global variable:
---
extern(C++) struct Foo
{
int x;
}
immutable foo1 = Foo(1);
extern(C++) void fun(const ref Foo foo = foo1);
---
Thanks. This appears to work, but feels
On Monday, 14 September 2020 at 12:44:34 UTC, 60rntogo wrote:
I'm trying to use a C++ library that has a function declared
like this:
---
struct Foo
{
int x;
};
void fun(const Foo& foo = Foo(1));
---
I have translated this to a D declaration:
---
struct Foo
{
int x;
}
extern(C++)
On Monday, 14 September 2020 at 12:44:34 UTC, 60rntogo wrote:
---
struct Foo
{
int x;
}
extern(C++) void fun(const ref Foo foo = Foo(1));
---
I suppose this should have been:
---
extern(C++):
struct Foo
{
int x;
}
void fun(const ref Foo foo = Foo(1));
---
Not that it changes
I'm trying to use a C++ library that has a function declared like
this:
---
struct Foo
{
int x;
};
void fun(const Foo& foo = Foo(1));
---
I have translated this to a D declaration:
---
struct Foo
{
int x;
}
extern(C++) void fun(const ref Foo foo = Foo(1));
---
This yields an e
On Saturday, 1 February 2020 at 14:52:21 UTC, kinke wrote:
Trivial cases like yours should actually work wrt. using C++
ctor implementations from D IIRC.
Ah, you need at least one virtual function in the C++ class
(because D always reserves a vptr, the pointer to the class
vtable).
On Saturday, 1 February 2020 at 08:15:20 UTC, Luhrel wrote:
But somehow I got a segfault on dcpp.getNumber(true).
That's because you declare it as virtual in D (default for
classes, use `final`), but non-virtual in C++. You also forgot to
add the class field to the D declaration (yes, D
On Saturday, 1 February 2020 at 10:21:54 UTC, norm wrote:
On Saturday, 1 February 2020 at 08:38:22 UTC, Luhrel wrote:
On Saturday, 1 February 2020 at 08:32:51 UTC, Ferhat Kurtulmuş
wrote:
On Saturday, 1 February 2020 at 08:27:07 UTC, Luhrel wrote:
On Saturday, 1 February 2020 at 08:21:29 UTC,
On Saturday, 1 February 2020 at 08:38:22 UTC, Luhrel wrote:
On Saturday, 1 February 2020 at 08:32:51 UTC, Ferhat Kurtulmuş
wrote:
On Saturday, 1 February 2020 at 08:27:07 UTC, Luhrel wrote:
On Saturday, 1 February 2020 at 08:21:29 UTC, Ferhat
Kurtulmuş wrote:
You cannot.
On Saturday, 1 February 2020 at 08:32:51 UTC, Ferhat Kurtulmuş
wrote:
On Saturday, 1 February 2020 at 08:27:07 UTC, Luhrel wrote:
On Saturday, 1 February 2020 at 08:21:29 UTC, Ferhat Kurtulmuş
wrote:
You cannot.
https://dlang.org/spec/cpp_interface.html#using_cpp_classes_from_d
You must
On Saturday, 1 February 2020 at 08:27:07 UTC, Luhrel wrote:
On Saturday, 1 February 2020 at 08:21:29 UTC, Ferhat Kurtulmuş
wrote:
You cannot.
https://dlang.org/spec/cpp_interface.html#using_cpp_classes_from_d
You must use a factory method like createInstance.
Oh I see, so there's
On Saturday, 1 February 2020 at 08:21:29 UTC, Ferhat Kurtulmuş
wrote:
You cannot.
https://dlang.org/spec/cpp_interface.html#using_cpp_classes_from_d
You must use a factory method like createInstance.
Oh I see, so there's definitively no way to call a c++ ctor
without modifying the c++
On Saturday, 1 February 2020 at 08:15:20 UTC, Luhrel wrote:
Hello there,
I would like to know how can I call a C++ ctor.
[...]
You cannot.
https://dlang.org/spec/cpp_interface.html#using_cpp_classes_from_d
You must use a factory method like createInstance.
show);
void add(int num);
};
D:
app.d
import std.stdio;
void main()
{
auto dcpp = new AmazingCppClass();
dcpp.getNumber(true); //segfault here
}
extern(C++) class AmazingCppClass
{
this();
int getNumber(bool show);
Saturday, 7 September 2019 at 17:22:07 UTC, Jonathan M Davis
> >>
> >> wrote:
> >> > @safe:
> >> > @system:
> >> >
> >> > then @system overrides @safe.
> >>
> >> Just to add onto this, you can't do:
> >>
Just to add onto this, you can't do:
@safe @system void foo(); // error
but you can do:
extern(C++, ns1) extern(C++, ns2) void foo(); // ok
It makes no sense to apply multiple namespaces to the same
symbol. I expect that this behavior is due to a lack of testing
(the same with the
On Sunday, 8 September 2019 at 09:35:03 UTC, Jonathan M Davis
wrote:
The C++ support has been improved kind of piecemeal over time,
and initially, none of it was documented. So, it wasn't exactly
fully planned out when it was added. IIRC, it was added
originally so that the dmd frontend
t;> On Saturday, 7 September 2019 at 17:22:07 UTC, Jonathan M Davis
> >>
> >> wrote:
> >> > @safe:
> >> > @system:
> >> >
> >> > then @system overrides @safe.
> >>
> >> Just to add onto this, you can't do:
> >>
Just to add onto this, you can't do:
@safe @system void foo(); // error
but you can do:
extern(C++, ns1) extern(C++, ns2) void foo(); // ok
It makes no sense to apply multiple namespaces to the same
symbol. I expect that this behavior is due to a lack of testing
(the same with the
On Saturday, September 7, 2019 2:18:40 PM MDT Jonathan M Davis via
Digitalmars-d-learn wrote:
> On Saturday, September 7, 2019 8:53:54 AM MDT Max Samukha via
> Digitalmars-d-
> learn wrote:
> > extern(C++, "ns1") {
> >
> > extern(C++,
n't do:
>
> @safe @system void foo(); // error
>
>
> but you can do:
>
> extern(C++, ns1) extern(C++, ns2) void foo(); // ok
It makes no sense to apply multiple namespaces to the same symbol. I expect
that this behavior is due to a lack of testing (the same with the out o
On Saturday, 7 September 2019 at 17:22:07 UTC, Jonathan M Davis
wrote:
@safe:
@system:
then @system overrides @safe.
Just to add onto this, you can't do:
@safe @system void foo(); // error
but you can do:
extern(C++, ns1) extern(C++, ns2) void foo(); // ok
On Saturday, 7 September 2019 at 17:22:07 UTC, Jonathan M Davis
wrote:
makes no sense whatsoever IMHO. IIRC, this version of
extern(C++) didn't go through the DIP process and was simply
added via a PR.
The original extern(C++) worked the same way. Since it was
implemented in v2.066.0
On Saturday, September 7, 2019 8:53:54 AM MDT Max Samukha via Digitalmars-d-
learn wrote:
> extern(C++, "ns1") {
> extern(C++, ns2) {
> extern(C++, "ns3") {
> extern(C++, ns4) {
> void foo();
> }
>
On Saturday, September 7, 2019 9:15:44 AM MDT Max Samukha via Digitalmars-d-
learn wrote:
> extern(C++, "ns1"):
> extern(C++, "ns2"): // Not in nested scope. Should it supersede?
> void foo();
>
> pragma(msg, foo.mangleof); // _ZN3ns13ns23fooEv
extern(C++, "ns1"):
extern(C++, "ns2"): // Not in nested scope. Should it supersede?
void foo();
pragma(msg, foo.mangleof); // _ZN3ns13ns23fooEv instead of
expected _ZN3ns23fooEv
Is that by design?
extern(C++, "ns1") {
extern(C++, ns2) {
extern(C++, "ns3") {
extern(C++, ns4) {
void foo();
}
}
}
}
pragma(msg, foo.mangleof); // _ZN3n
On Saturday, 7 September 2019 at 13:01:38 UTC, Jacob Carlborg
wrote:
On 2019-09-06 21:03, Max Samukha wrote:
Is there any practical use of having identically named .d and
.di alongside?
Same as in C/C++. This allows you to have a header file if you
want to distribute a closed source
On 2019-09-06 21:03, Max Samukha wrote:
Is there any practical use of having identically named .d and .di
alongside?
Same as in C/C++. This allows you to have a header file if you want to
distribute a closed source library.
--
/Jacob Carlborg
On Friday, 6 September 2019 at 17:54:51 UTC, Adam D. Ruppe wrote:
On Friday, 6 September 2019 at 17:42:08 UTC, Max Samukha wrote:
That file was silently imported by the compiler (probably, a
bug).
That's by design - the automatic module import lookups actually
always look for .di file first,
On Friday, 6 September 2019 at 17:42:08 UTC, Max Samukha wrote:
That file was silently imported by the compiler (probably, a
bug).
That's by design - the automatic module import lookups actually
always look for .di file first, then .d files.
On Friday, 6 September 2019 at 16:55:31 UTC, Max Samukha wrote:
On Friday, 6 September 2019 at 15:52:46 UTC, Stefan Koch wrote:
If that is happening you hit a bug.
It seems unlikely though.
Could you elaborate a bit? How should extern(C/C++) definitions
be mangled - fully qualified
On Friday, 6 September 2019 at 15:52:46 UTC, Stefan Koch wrote:
On Friday, 6 September 2019 at 15:09:22 UTC, Max Samukha wrote:
Consider the following two modules:
1. test.d:
module test;
import lib.a;
void main() {
foo();
}
2. lib/a.d:
module lib.a;
extern(C) void foo() {}
When
On Friday, 6 September 2019 at 15:32:07 UTC, 0xEAB wrote:
On Friday, 6 September 2019 at 15:09:22 UTC, Max Samukha wrote:
Consider the following two modules:
What compiler version are you using?
DMD64 D Compiler v2.088.0-1-g4011382ea, linux
On Friday, 6 September 2019 at 15:09:22 UTC, Max Samukha wrote:
Consider the following two modules:
1. test.d:
module test;
import lib.a;
void main() {
foo();
}
2. lib/a.d:
module lib.a;
extern(C) void foo() {}
When compiled separately (dmd -c lib/a.d; dmd test.d a.o
On Friday, 6 September 2019 at 15:09:22 UTC, Max Samukha wrote:
Consider the following two modules:
What compiler version are you using?
Consider the following two modules:
1. test.d:
module test;
import lib.a;
void main() {
foo();
}
2. lib/a.d:
module lib.a;
extern(C) void foo() {}
When compiled separately (dmd -c lib/a.d; dmd test.d a.o), the
function in 'a.o' is mangled as 'foo', but the reference in
'test.o
1 - 100 of 324 matches
Mail list logo
