Re: LNK2019 error in the C++ interface
On Thursday, 10 June 2021 at 15:19:27 UTC, kinke wrote: Confirmed: https://issues.dlang.org/show_bug.cgi?id=22014 Thank you for the bug report. I'm glad I couldn't handle it myself. The only thing that bothers me is that there is no sign of this problem being fixed. I fear that this may be the case forever. On Thursday, 10 June 2021 at 15:19:27 UTC, kinke wrote: Wrt. `tagRECT`, this should come in handy (for a druntime fix): https://dlang.org/changelog/2.097.0.html#pragma-mangle-aggregate I don't see how this helps with the modifications related to tagRECT.
Re: LNK2019 error in the C++ interface
On Thursday, 10 June 2021 at 13:19:34 UTC, dokutoku wrote: The reason seems to be that WCHAR should be mangled with wcha_t, but it is mangled with chat16_t. Confirmed: https://issues.dlang.org/show_bug.cgi?id=22014 Wrt. `tagRECT`, this should come in handy (for a druntime fix): https://dlang.org/changelog/2.097.0.html#pragma-mangle-aggregate
Re: LNK2019 error in the C++ interface
On Thursday, 10 June 2021 at 13:19:34 UTC, dokutoku wrote: I still haven't solved this problem. Not sure if this is the issue, but you don't need `extern` on these. You already have the `extern(C++)` thing at the top of the file. ```d extern void str_test(LPCSTR str1); nothrow @nogc extern void wstr_test(LPCWSTR str1); ```
Re: LNK2019 error in the C++ interface
It's been a while since then, but the problem with the structure
has been solved.
The reason seems to be that the structure name defined in
core.sys.windows.windef was not tagRECT.
I was able to get it to compile by adding a custom definition as
follows
```d
extern (C)
struct tagRECT
{
LONG left;
LONG top;
LONG right;
LONG bottom;
}
alias RECT = tagRECT;
```
The type name did not work.
The reason seems to be that WCHAR should be mangled with wcha_t,
but it is mangled with chat16_t.
Since the mangle is wchat_t, I thought maybe I should use wchar_t
in core.stdc.stdef, so I changed LPCWSTR to const (wchar_t)*, but
that didn't work either.
I still haven't solved this problem.
I also took a look at Data Type Compatibility in Interfacing to
C++, and I think it's wrong about wchar_t.
https://dlang.org/spec/cpp_interface.html#data-type-compatibility
