Re: trait to get the body code of a function?
On 25/07/2018 5:32 AM, Guillaume Lathoud wrote: Thanks for all the answers. I've just had a look at an alternative: using dmd as a package. However that's a lot of doc to browse... Maybe someone has experience with dmd as a package? Not a solution. Leaks memory, not reusable and in general not very friendly to work with.
Re: extern(C++): Unresolved scalar deleting destructor
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
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
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
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: trait to get the body code of a function?
On Tuesday, 24 July 2018 at 14:26:45 UTC, 12345swordy wrote: On Tuesday, 24 July 2018 at 05:27:36 UTC, rikki cattermole wrote: On 24/07/2018 4:43 PM, Guillaume Lathoud wrote: [...] Doesn't exist. Well, IMO it should exist as it can be quite useful for generating metainfo. Thanks for all the answers. I've just had a look at an alternative: using dmd as a package. However that's a lot of doc to browse... Maybe someone has experience with dmd as a package? Otherwise I'll just stick to strings, but it'd be nice to have. Best regards, Guillaume
Re: Windows 7 x64. Prevent appearing of console with GUI application
On Tuesday, 24 July 2018 at 09:20:22 UTC, Mike Parker wrote:
On Tuesday, 24 July 2018 at 08:09:33 UTC, ANtlord wrote:
Anyway, if you are using OPTLINK or the MS Linker, try a test
program without gtkD to make sure it works standalone for you.
```
import core.sys.windows.windows;
void main() {
MessageBoxA(null, "Look, Ma! No console!", "It works!",
MB_OK);
}
```
You partially are right, the issue is related to the application
internals but not to GTKD. I forgot that I launch the second
application inside. I recompiled both of the with
-L/SUBSYSTEM:windows -L/ENTRY:mainCRTStartup and that's it.
Thanks a lot everyone!
Re: extern(C++): Unresolved scalar deleting destructor
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
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
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?
Re: trait to get the body code of a function?
On Tuesday, 24 July 2018 at 05:27:36 UTC, rikki cattermole wrote: On 24/07/2018 4:43 PM, Guillaume Lathoud wrote: [...] Doesn't exist. Well, IMO it should exist as it can be quite useful for generating metainfo.
Re: How to avoid inout type constructor with Optional type wrapper undoing string type
On 07/24/2018 02:47 AM, Timoses wrote:
> Why does this fail while it works when replacing T with U in struct
> W(T)?? It's so odd. Both T and U seem to resolve to "string".
>
> struct W(T) {
> const T value;
> // Replacing `T value` with `U value` compiles
> this(U : T)(auto ref const T value) {
That means, "any U that can implicitly be converted to string". However,
when U does not appear in the function parameter list, there is no way
for the compiler to deduce U. (I don't think there is syntax to specify
constructor template parameters explicitly.)
And if the parameter is always T, why is the constructor a template? Ok,
perhaps U is used inside the constructor and the programmer needs to
specify it... Still, I don't think there is such syntax.
Ali
Re: trait to get the body code of a function?
On Tuesday, 24 July 2018 at 04:43:33 UTC, Guillaume Lathoud wrote: Hello, __traits and std.traits already offer access to function information like input parameters, e.g. in std.traits: ParameterIdentifierTuple ParameterStorageClassTuple Even if that might sound strange, is there a compile time access to the body of the function, e.g. as a code string, or at least to the filename where it was declared? I have not found a direct "string" access, but I found these: https://dlang.org/phobos/std_traits.html#moduleName https://dlang.org/phobos/std_traits.html#packageName ...and I am not sure how to proceed from here to get the code as a string that declared the function. Context: I have some compile-time ideas in mind (code transformation). Best regards, Guillaume Lathoud Not sure if this could be of interest: https://forum.dlang.org/thread/ifllo2$a45$1...@digitalmars.com
Re: How to avoid inout type constructor with Optional type wrapper undoing string type
On Monday, 23 July 2018 at 18:39:59 UTC, aliak wrote:
Hi,
I'm playing around with an Optional wrapper type. It stores a
type T and a bool that defines whether a value is defined or
not:
struct Optional(T) {
T value;
bool defined = false;
this(U : T)(auto ref inout(U) value) inout {
this.value = value;
this.defined = true;
}
}
To facilitate it's use I have two type constructors:
inout(Optional!T) some(T)(auto ref inout(T) value) {
return inout(Optional!T)(value);
}
Optional!T no(T)() {
return Optional!T();
}
The above produces a problem when working with strings.
Basically the type information gets slightly altered so you
can't do this:
auto a = [no!string, some("hello")];
You get a type mismatch:
* no!string = Optional!string
* some("hello") = immutable(Optional!(char[]))
I've created a short code gist, so basically I'm wondering how
to get it to compile without changing what's in main()
https://run.dlang.io/is/BreNdZ
I guess I can specialize on string type T, but this is a more
general problem that can be shown with:
struct S {}
alias Thing = immutable S;
Thing thing = S();
auto x = some(thing);
auto y = no!Thing;
auto arr = [x, y]; // no can do buddy
Cheers,
- Ali
I'm not being very helpful here, just throwing in more questions
again:
Why does this fail while it works when replacing T with U in
struct W(T)?? It's so odd. Both T and U seem to resolve to
"string".
struct W(T) {
const T value;
// Replacing `T value` with `U value` compiles
this(U : T)(auto ref const T value) {
pragma(msg, T); // string
pragma(msg, U); // string
this.value = value;
}
}
auto defined(T)(auto ref const T value) {
return W!T(value);
}
void main() {
auto a = defined("hello");
}
Is this a bug?
Re: Windows 7 x64. Prevent appearing of console with GUI application
On Tuesday, 24 July 2018 at 08:09:33 UTC, ANtlord wrote:
Hello! I'm trying run my GUI application getting a console
hidden. The application is on top of GTKD, compiled with dmd
2.081.1 in Windows 7 x64. I read a few threads on the forum and
StackOverflow and I got that I need to add a module definition
file [1] or to add -L/SUBSYSTEM:WINDOWS -L/ENTRY:mainCRTStartup
options to compiler [2] or to add only /SUBSYSTEM:WINDOWS [3]
or use a command getting console hidden [4].
I've never used a module definition file for this. The
/subsystem:windows switch has always worked for me. When linking
with OPTLINK, that's all you need. When using the MS linker,
you'll need that along with the /ENTRY:mainCRTStartup. With
recent versions, if you don't have the MS tools installed, you'll
get the LLVM linker when using -m64 or -m43mscoff. If that's the
case, I don't know that it even supports changing the subsystem
or, if it does, what the syntax looks like. A cursory search
turns up nothing.
Anyway, if you are using OPTLINK or the MS Linker, try a test
program without gtkD to make sure it works standalone for you.
```
import core.sys.windows.windows;
void main() {
MessageBoxA(null, "Look, Ma! No console!", "It works!",
MB_OK);
}
```
Both of the following command lines work for me.
With OPTLINK:
dmd -L/SUBSYSTEM:windows win.d
With the MS linker:
dmd -m64 -L/SUBSYSTEM:windows -L/ENTRY:mainCRTStartup win.d
user32.lib
Re: Windows 7 x64. Prevent appearing of console with GUI application
On Tuesday, 24 July 2018 at 08:48:54 UTC, Mike Franklin wrote: Here's my test extern (Windows) int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int iCmdShow) When using WinMain, subsystem:windows is the default. The OP wants to use main as the entry point, where the console subsystem is the default.
Re: Windows 7 x64. Prevent appearing of console with GUI application
On Tuesday, 24 July 2018 at 08:09:33 UTC, ANtlord wrote:
So... how prevent appearing of console on the startup of the
application?
Here's my test
---
module HelloMsg;
import core.runtime;
import std.utf;
import core.sys.windows.windows;
auto toUTF16z(S)(S s)
{
return toUTFz!(const(wchar)*)(s);
}
extern (Windows)
int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int iCmdShow)
{
int result;
void exceptionHandler(Throwable e) { throw e; }
try
{
Runtime.initialize();
result = myWinMain(hInstance, hPrevInstance, lpCmdLine,
iCmdShow);
Runtime.terminate();
}
catch (Throwable o)
{
MessageBox(null, o.toString().toUTF16z, "Error", MB_OK |
MB_ICONEXCLAMATION);
result = 0;
}
return result;
}
int myWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int iCmdShow)
{
MessageBox(NULL, "Hello, Windows!", "Your Application", 0);
return 0;
}
---
dmd -L/SUBSYSTEM:WINDOWS main.d
main.obj : error LNK2019: unresolved external symbol MessageBoxW
referenced in function WinMain
dmd -L/SUBSYSTEM:WINDOWS main.d User32.lib
Success!
Executing from PowerShell: no console
Executing from Command Prompt: no console
Double-clicking in Explorer: no console
Windows 10 64-bit
Mike
Windows 7 x64. Prevent appearing of console with GUI application
Hello! I'm trying run my GUI application getting a console hidden. The application is on top of GTKD, compiled with dmd 2.081.1 in Windows 7 x64. I read a few threads on the forum and StackOverflow and I got that I need to add a module definition file [1] or to add -L/SUBSYSTEM:WINDOWS -L/ENTRY:mainCRTStartup options to compiler [2] or to add only /SUBSYSTEM:WINDOWS [3] or use a command getting console hidden [4]. Actually no one case works properly. The first one doesn't affect, the second "unbinds" appeared console giving ability to close it without closing the application, the third one raises a linker error about unresolved symbol WinMain, the fourth one hides a console but it does it with delay. Also, I tried to use `editbin /SUBSYSTEM:windows myapp.exe` but I it doesn't affect anything. Here is my dub.json [5] So... how prevent appearing of console on the startup of the application? [1] https://wiki.dlang.org/D_for_Win32 [2] https://forum.dlang.org/post/bhswtzoklrzzslliq...@forum.dlang.org [3] https://forum.dlang.org/post/qcejigllwticykoiw...@forum.dlang.org [4] https://stackoverflow.com/a/2139903 [5] http://vpaste.net/mEy2P
