Re: extern(C++): Unresolved scalar deleting destructor

2018-07-25 Thread Vladimir Marchevsky via Digitalmars-d-learn
On Wednesday, 25 July 2018 at 12:04:16 UTC, Vladimir Marchevsky 
wrote:

What I've tested:


Even more: if I create another trivial class in cpp (say, Bar) 
and new/delete it in first one ("b = new Bar();" in ctor, "delete 
b;" in dtor of Foo) - D app with bound Foo just crashes silently 
for some reason.


Re: extern(C++): Unresolved scalar deleting destructor

2018-07-25 Thread Vladimir Marchevsky via Digitalmars-d-learn

Back to questions after homework done :) What I've tested:

Made test class in CPP:

---testlib.cpp
class __declspec(dllexport) Foo {
int *a;

public:
Foo(int value) {
a = new int(value);
}

~Foo() {
delete a;
}
};
---

Binding on D side:

---
extern(C++) {
class Foo {
this(int value);
final ~this();//btw, is this a correct way to bind a 
non-virtual member?

  //What about inheritance and so on?..
}
}
---

Binding works perfect, both ctor and dtor work.

Changed dtor to be virtual (and removed final from D side) - 
anyway, compiles and works perfect. I can provide D 
implementation of destructor which replaces original virtual one 
(is it correct? Or can I call original one from D-specified?) - 
making it empty leads to memory leak as expected. So I see no 
problems here.


Back to QObject. Its destructor is "virtual ~QObject();" but 
having "~this();" on D side again leads to "unresolved scalar 
deleting destructor" of QObject. It looks like actual destructor 
binds correct (I would have another error if I make binding 
incorrect with "final ~this()") but for some reason it wants this 
another thing... Why?


Re: extern(C++): Unresolved scalar deleting destructor

2018-07-24 Thread Vladimir Marchevsky via Digitalmars-d-learn

On Tuesday, 24 July 2018 at 19:30:49 UTC, 12345swordy wrote:

I found similar error messages regarding c++:
https://stackoverflow.com/questions/42449063/vs-c-dll-scalar-deleteing-destructor


Hmm, so looks like it's really because of virtual destructor, 
like Stefan mentioned before. Implementing empty destructor in D 
removes error. Gonna check what C++ does in similar case and any 
possible problems...


Thanks to everyone for pointing out the direction to dig :)


Re: extern(C++): Unresolved scalar deleting destructor

2018-07-24 Thread 12345swordy via Digitalmars-d-learn
On Tuesday, 24 July 2018 at 19:14:26 UTC, Vladimir Marchevsky 
wrote:

On Tuesday, 24 July 2018 at 19:04:50 UTC, 12345swordy wrote:

Have you tried @disable ~this()?


Just tried:
1) no changes, still error about unresolved "QObject::`scalar 
deleting destructor'(unsigned int)".
2) marking destructor as @disable will actually disable it, 
right? But I want to use to not receive a memory leak. Afaik, 
previous approach was to re-implement ctor/dtor in D but now 
they can be used as they are.

I found similar error messages regarding c++:
https://stackoverflow.com/questions/42449063/vs-c-dll-scalar-deleteing-destructor


Re: extern(C++): Unresolved scalar deleting destructor

2018-07-24 Thread Vladimir Marchevsky via Digitalmars-d-learn

On Tuesday, 24 July 2018 at 19:04:50 UTC, 12345swordy wrote:

Have you tried @disable ~this()?


Just tried:
1) no changes, still error about unresolved "QObject::`scalar 
deleting destructor'(unsigned int)".
2) marking destructor as @disable will actually disable it, 
right? But I want to use to not receive a memory leak. Afaik, 
previous approach was to re-implement ctor/dtor in D but now they 
can be used as they are.


Re: extern(C++): Unresolved scalar deleting destructor

2018-07-24 Thread 12345swordy via Digitalmars-d-learn
On Tuesday, 24 July 2018 at 15:48:28 UTC, Vladimir Marchevsky 
wrote:
After reading 2.081 patchnotes about improvements with binding 
to cpp classes, I'm trying to test it - with simple examples 
and Qt as cpp library.


[...]


Have you tried @disable ~this()?

Alexander


Re: extern(C++): Unresolved scalar deleting destructor

2018-07-24 Thread Vladimir Marchevsky via Digitalmars-d-learn

On Tuesday, 24 July 2018 at 16:30:41 UTC, Stefan Koch wrote:

Seems like it's virtual destructor could that be?

this qt5 binding: 
https://github.com/MGWL/QtE5/blob/master/source/qte5.d

seems to always define the constructor.


No, simple virtual (or final) destructor binds just fine with 
"~this()" or "final ~this()". "Scalar deleting destructor" is 
special thing, afaik, and my C++ knowledge is not enough to 
determine why is it required by D side and not required in C++ or 
not available in compiled lib.


QtE5, DQml or similar projects mostly wrap cpp-objects - create 
them on cpp side with helper function, save returned pointer on d 
side and operate via wrapper-functions that call methods on cpp 
side. But it looks I should be mostly able to interact with 
cpp-defined classes directly now, from 2.081 patchnotes:


"This release also includes ABI fixes where destructors are now 
correctly added to the virtual table, and constructor/destructor 
calling semantics now match C++. With this, mixed-language class 
hierarchies are working, with construction/destruction being 
supported in either language."


Re: extern(C++): Unresolved scalar deleting destructor

2018-07-24 Thread Stefan Koch via Digitalmars-d-learn
On Tuesday, 24 July 2018 at 15:48:28 UTC, Vladimir Marchevsky 
wrote:
After reading 2.081 patchnotes about improvements with binding 
to cpp classes, I'm trying to test it - with simple examples 
and Qt as cpp library.


My naive approach is to bind just a couple of used methods of 
specific classes (omitting others) and try to use it directly 
in D just with linking of default Qt5Core.lib. Sometimes it 
works just fine:


---app.d
import std.conv;
import std.stdio;

extern(C++) {
class QVariant {
this();
this(int);
this(double);
final ~this();

final int toInt(bool *ok = null) const;
final double toDouble(bool *ok = null) const;
}
}

void main()
{
QVariant a = new QVariant(5);
QVariant b = new QVariant(5.5);
writeln("a: " ~ a.toInt().to!string);
writeln("b: " ~ b.toDouble().to!string);
readln();
}
---

This example compiles and works like a charm.

Other classes like QObject or QCoreApplication do not link with 
error like this:


cpptest.obj : error LNK2001: unresolved external symbol 
""public: virtual void * __cdecl QObject::`scalar deleting 
destructor'(unsigned int)" (??_GQObject@@UEAAPEAXI@Z)"


There is no such symbol in Qt5Core.lib, obviously. Is it my 
mistake somewhere? Why do some classes require this destructor 
when it doesnt actually exist in lib? And why do other classes 
work without it?


Seems like it's virtual destructor could that be?

this qt5 binding: 
https://github.com/MGWL/QtE5/blob/master/source/qte5.d

seems to always define the constructor.



extern(C++): Unresolved scalar deleting destructor

2018-07-24 Thread Vladimir Marchevsky via Digitalmars-d-learn
After reading 2.081 patchnotes about improvements with binding to 
cpp classes, I'm trying to test it - with simple examples and Qt 
as cpp library.


My naive approach is to bind just a couple of used methods of 
specific classes (omitting others) and try to use it directly in 
D just with linking of default Qt5Core.lib. Sometimes it works 
just fine:


---app.d
import std.conv;
import std.stdio;

extern(C++) {
class QVariant {
this();
this(int);
this(double);
final ~this();

final int toInt(bool *ok = null) const;
final double toDouble(bool *ok = null) const;
}
}

void main()
{
QVariant a = new QVariant(5);
QVariant b = new QVariant(5.5);
writeln("a: " ~ a.toInt().to!string);
writeln("b: " ~ b.toDouble().to!string);
readln();
}
---

This example compiles and works like a charm.

Other classes like QObject or QCoreApplication do not link with 
error like this:


cpptest.obj : error LNK2001: unresolved external symbol ""public: 
virtual void * __cdecl QObject::`scalar deleting 
destructor'(unsigned int)" (??_GQObject@@UEAAPEAXI@Z)"


There is no such symbol in Qt5Core.lib, obviously. Is it my 
mistake somewhere? Why do some classes require this destructor 
when it doesnt actually exist in lib? And why do other classes 
work without it?