On Monday, 29 October 2018 at 01:03:32 UTC, kinke wrote:
export extern(C) extern __gshared int myIntValue;
Bingo!! That did the trick. Thank you so much.
On Monday, 29 October 2018 at 00:01:21 UTC, DanielG wrote:
DLLPROJECT_API
I guess that's a __declspec(dllexport); in that case try
export extern(C) extern __gshared int myIntValue;
=> that's dllimport for extern variables, and dllexport for
non-extern ones.
On Monday, 29 October 2018 at 00:52:32 UTC, kinke wrote:
The names it spits out are undecorated
Correction: they *are* the decorated ones, i.e., the real final
names.
On Monday, 29 October 2018 at 00:01:21 UTC, DanielG wrote:
[...]
I'd examine the dumpbin output of your (native) import library,
e.g., `dumpbin /symbols blub.lib`. You can also list exports etc.
The names it spits out are undecorated, i.e., C symbols for Win32
libs will feature the implicit
On Monday, 29 October 2018 at 00:12:43 UTC, DanielG wrote:
It's defined in the .cpp file.
Ah, of course, good.
The other thing that might be an issue is the leading _ the
compiler frequently adds. You might be able to hack it with
pragma(mangle, "myIntValue") on the declaration too. idk for
On Monday, 29 October 2018 at 00:16:38 UTC, Stanislav Blinov
wrote:
Should it be extern(Windows), perchance?.. (I haven't D on
Windows for ages).
The stdcall calling convention? I think that would only matter
for the function, and indeed, trying that breaks the function
being able to link**
On Monday, 29 October 2018 at 00:01:21 UTC, DanielG wrote:
In my D app I'm declaring it this way:
extern (C) {
extern __gshared int myIntValue;
int myIntFunc (int a, int b);
}
The function seems to link OK, but the C global will not.
Should it be extern(Windows),
On Monday, 29 October 2018 at 00:04:54 UTC, Adam D. Ruppe wrote:
Both are listed as extern, where is the actual variable stored?
If it is in the dll, it shouldn't be extern there.
It's defined in the .cpp file. This is how the built-in DLL
template generates it - "extern" in the .h file,
So I have a DLL+LIB exporting this:
extern "C" {
extern DLLPROJECT_API int myIntValue;
DLLPROJECT_API int myIntFunc(int a, int b);
}
In my D app I'm declaring it this way:
extern (C) {
extern __gshared int myIntValue;
int myIntFunc (int a, int b);
}
The
On Monday, 29 October 2018 at 00:01:21 UTC, DanielG wrote:
extern DLLPROJECT_API int myIntValue;
extern __gshared int myIntValue;
Both are listed as extern, where is the actual variable stored?
If it is in the dll, it shouldn't be extern there.
Thanks for excellent explanation!
On Sunday, 28 October 2018 at 19:00:52 UTC, Jonathan M Davis
wrote:
Because Object predats @safe (and most attributes), it really
isn't compatible with them. In fact, it predates const (since
it's basically the same as it was in D1) and it's only possible
On Sunday, October 28, 2018 12:56:10 PM MDT ikod via Digitalmars-d-learn
wrote:
> On Sunday, 28 October 2018 at 18:00:06 UTC, Stanislav Blinov
>
> wrote:
> > On Sunday, 28 October 2018 at 12:38:12 UTC, ikod wrote:
> >> and object.opEquals(a,b) do not inherits safety from class C
> >> properties,
On Sunday, October 28, 2018 6:38:12 AM MDT ikod via Digitalmars-d-learn
wrote:
> Hello
>
> How to make this code to compile? My goal is safe(not @trusted)
> longFunction().
>
>
> ---
> class C
> {
> override bool opEquals(Object o) const @safe
> {
> return true;
> }
> }
>
On Sunday, 28 October 2018 at 18:00:06 UTC, Stanislav Blinov
wrote:
On Sunday, 28 October 2018 at 12:38:12 UTC, ikod wrote:
and object.opEquals(a,b) do not inherits safety from class C
properties, and also I can't override it.
Yep. Since Object is the base class and it defines opEquals as:
On Sunday, October 28, 2018 12:17:41 PM MDT Neia Neutuladh via Digitalmars-
d-learn wrote:
> On Sun, 28 Oct 2018 18:00:06 +, Stanislav Blinov wrote:
> > On Sunday, 28 October 2018 at 12:38:12 UTC, ikod wrote:
> >> and object.opEquals(a,b) do not inherits safety from class C
> >> properties,
On Sun, 28 Oct 2018 18:00:06 +, Stanislav Blinov wrote:
> On Sunday, 28 October 2018 at 12:38:12 UTC, ikod wrote:
>
>> and object.opEquals(a,b) do not inherits safety from class C
>> properties, and also I can't override it.
>
> Yep. Since Object is the base class and it defines opEquals
On Sunday, 28 October 2018 at 12:38:12 UTC, ikod wrote:
and object.opEquals(a,b) do not inherits safety from class C
properties, and also I can't override it.
Yep. Since Object is the base class and it defines opEquals as:
```
bool opEquals(Object);
```
the compiler rewrites `a == b` as
Hello
How to make this code to compile? My goal is safe(not @trusted)
longFunction().
---
class C
{
override bool opEquals(Object o) const @safe
{
return true;
}
}
bool longFunction(C a, C b) @safe
{
return a==b;
}
void main()
{
}
---
As far as I understand the
On 28/10/2018 11:11 PM, DanielG wrote:
Wait, wut? Do modules that get pulled in from dub's "importPaths" not
get compiled in the same way?
No. They just get -I'd.
On Sunday, 28 October 2018 at 08:38:56 UTC, Nicholas Wilson wrote:
Oh yeah, I didn't think to mention that you need to compile
them for them to fix your missing symbols problem.
Wait, wut? Do modules that get pulled in from dub's "importPaths"
not get compiled in the same way?
The
On Sunday, 28 October 2018 at 06:59:31 UTC, DanielG wrote:
For the benefit of anybody who encounters a problem like this
in the future ... originally I had my C library "header" files
(renamed from .di to .d after the feedback from Nicholas) in a
special 'headers/' subdir, used as an import
For the benefit of anybody who encounters a problem like this in
the future ... originally I had my C library "header" files
(renamed from .di to .d after the feedback from Nicholas) in a
special 'headers/' subdir, used as an import path in dub.json. I
simply moved those files to the source
22 matches
Mail list logo
