Re: Passing nested template function
On Saturday, 10 August 2019 at 17:45:43 UTC, Prateek Nayak wrote: A nested function can be passed to another function evident from this example: https://run.dlang.io/is/6waRkB However if the nested function is a template function, it raises an error https://run.dlang.io/is/PQhkwl The error being: cannot get frame pointer to the nested function Is there a way to pass a nested template function to a function declared outside the outer function scope? The part I'm not sure about: This is not possible: Before instantiation, the object does not exist, you cannot, therefore, pass its pointer, not to speak about the pointer of its frame. However, how about this: https://run.dlang.io/is/8drZRf
Re: Passing nested template function
On Saturday, 10 August 2019 at 17:45:43 UTC, Prateek Nayak wrote:
A nested function can be passed to another function evident
from this example: https://run.dlang.io/is/6waRkB
However if the nested function is a template function, it
raises an error
https://run.dlang.io/is/PQhkwl
The error being: cannot get frame pointer to the nested function
Is there a way to pass a nested template function to a function
declared outside the outer function scope?
This looks like it could be a bug to me. If you explicitly
instantiate the nested template and call dispatch like
dispatch!(nested!0) then it works.
An alias template parameter can accept both a template and an
instantiated template. I.e.
template X(T) {}
alias A = X; // ok
alias B = X!int; // ok
So it's unclear what should happen. At the least, the defaulted
argument should be applied at the call site (Func(a)).
Note though that neither versions will work on ldc or gdc
however. Because there's a bug [0] that has only been fixed in
for dmd.
[0] https://github.com/dlang/dmd/pull/9282
Re: Abstract classes vs interfaces, casting from void*
On 10.08.19 16:29, John Colvin wrote:
Ok. What would go wrong (in D) if I just replaced every interface with
an abstract class?
interface A{}
interface B{}
class C: A,B{ }
Passing nested template function
A nested function can be passed to another function evident from this example: https://run.dlang.io/is/6waRkB However if the nested function is a template function, it raises an error https://run.dlang.io/is/PQhkwl The error being: cannot get frame pointer to the nested function Is there a way to pass a nested template function to a function declared outside the outer function scope?
Re: Abstract classes vs interfaces, casting from void*
On Saturday, 10 August 2019 at 14:29:03 UTC, John Colvin wrote:
On Saturday, 10 August 2019 at 10:11:15 UTC, Alex wrote:
On Saturday, 10 August 2019 at 08:20:46 UTC, John Colvin wrote:
On Friday, 9 August 2019 at 13:39:53 UTC, Simen Kjærås wrote:
Thanks for the extra detail.
Is there a solid reason to ever use an interface over an
abstract class? (Other than multiple inheritance).
I'm such a noob at anything related to OO.
The general question is tricky, as different languages differ
in details what is forced and what is allowed for abstract
classes and interfaces.
But roughly speaking, my opinion is: if you can/want to
provide some default behavior than you are about to write an
abstract class.
If you are about to provide information/restriction of
behavior, then this is more like an interface.
Ok. What would go wrong (in D) if I just replaced every
interface with an abstract class?
´´´
void main(){}
interface A { void fun(); }
abstract class B{ void fun(); }
class C : A{ void fun(){} }
class D : B{ /*override*/ void fun(){} }
´´´
case 1:
interface A and class C implementing interface A:
You don't need to "override" anything. You are forced to provide
an implementation of the function inside the class.
case 2:
abstract class B and class D inheriting from it:
You can but not have to provide an implementation of a function
inside the abstract class.
If I don't and do not provide any implementation inside D I get a
linker error. Don't how this case behaves on your system.
If you provide an implementation inside the abstract class, you
don't have to provide any in the derived one.
In any case, if you want to provide an implementation inside the
derived class you have to literally "override", as in D implicit
overrides are not allowed.
Re: How to run the dub bundle with dmd
On Saturday, 10 August 2019 at 15:42:39 UTC, rikki cattermole wrote: This is a crazy question but is your Windows install 64bit? yes. See the spec below https://ibb.co/M1TwY7W
Re: How to run the dub bundle with dmd
This is a crazy question but is your Windows install 64bit?
Re: How to run the dub bundle with dmd
On Saturday, 10 August 2019 at 15:17:56 UTC, Andre Pany wrote: On Saturday, 10 August 2019 at 14:06:11 UTC, greatsam4sure wrote: On Saturday, 10 August 2019 at 13:46:23 UTC, Andre Pany wrote: On Saturday, 10 August 2019 at 13:18:19 UTC, greatsam4sure wrote: [...] Can you make a screenshot of the popup? Kind regards Andre I have make a screenshot of the popup but I don't know to post here. Is there away to post a pix here Could you also please check wheter the dub executable is "signed". Maybe this was forgotten in the recent version and now causing the issue. Kind regards Andre dub is digitally sign. It says name of signer: D language foundation I have download dub for GitHub but I cannot build it with dub or rdmd. It gives the same error on the screenshot
Re: How to run the dub bundle with dmd
On Saturday, 10 August 2019 at 15:17:56 UTC, Andre Pany wrote: On Saturday, 10 August 2019 at 14:06:11 UTC, greatsam4sure wrote: On Saturday, 10 August 2019 at 13:46:23 UTC, Andre Pany wrote: On Saturday, 10 August 2019 at 13:18:19 UTC, greatsam4sure wrote: [...] Can you make a screenshot of the popup? Kind regards Andre I have make a screenshot of the popup but I don't know to post here. Is there away to post a pix here Could you also please check wheter the dub executable is "signed". Maybe this was forgotten in the recent version and now causing the issue. Kind regards Andre thanks, below is the link to the screenshot https://ibb.co/CJLNQ6t
Re: How to run the dub bundle with dmd
On Saturday, 10 August 2019 at 14:06:11 UTC, greatsam4sure wrote: On Saturday, 10 August 2019 at 13:46:23 UTC, Andre Pany wrote: On Saturday, 10 August 2019 at 13:18:19 UTC, greatsam4sure wrote: [...] Can you make a screenshot of the popup? Kind regards Andre I have make a screenshot of the popup but I don't know to post here. Is there away to post a pix here Could you also please check wheter the dub executable is "signed". Maybe this was forgotten in the recent version and now causing the issue. Kind regards Andre
Re: How to run the dub bundle with dmd
On Saturday, 10 August 2019 at 14:06:11 UTC, greatsam4sure wrote: On Saturday, 10 August 2019 at 13:46:23 UTC, Andre Pany wrote: On Saturday, 10 August 2019 at 13:18:19 UTC, greatsam4sure wrote: [...] Can you make a screenshot of the popup? Kind regards Andre I have make a screenshot of the popup but I don't know to post here. Is there away to post a pix here Please use a free service and paste the link here. This is the first link I found on Google https://imgbb.com/ Kind regards Andre
Re: LNK4255 warning - should I be concerned?
On Saturday, 10 August 2019 at 13:08:39 UTC, Dukc wrote: Let me guess, you're linking Vibe.D? I get those errors all the time while using it. Haven't noticed effect on behaviour but it might be related to why it won't compile as 32-bit. No, this is mostly with own code with I believe just one dependency (automem). Seems to work in both x86_mscoff and x86_64 (aside from the warning). But yeah, when googling this warning, all I found was people talking about it in the context of Vibe.D.
Re: Abstract classes vs interfaces, casting from void*
On Saturday, 10 August 2019 at 10:11:15 UTC, Alex wrote: On Saturday, 10 August 2019 at 08:20:46 UTC, John Colvin wrote: On Friday, 9 August 2019 at 13:39:53 UTC, Simen Kjærås wrote: Thanks for the extra detail. Is there a solid reason to ever use an interface over an abstract class? (Other than multiple inheritance). I'm such a noob at anything related to OO. The general question is tricky, as different languages differ in details what is forced and what is allowed for abstract classes and interfaces. But roughly speaking, my opinion is: if you can/want to provide some default behavior than you are about to write an abstract class. If you are about to provide information/restriction of behavior, then this is more like an interface. Ok. What would go wrong (in D) if I just replaced every interface with an abstract class?
Re: Abstract classes vs interfaces, casting from void*
On Saturday, 10 August 2019 at 10:02:02 UTC, Antonio Corbi wrote: On Saturday, 10 August 2019 at 08:20:46 UTC, John Colvin wrote: On Friday, 9 August 2019 at 13:39:53 UTC, Simen Kjærås wrote: Thanks for the extra detail. Is there a solid reason to ever use an interface over an abstract class? (Other than multiple inheritance). I'm such a noob at anything related to OO. Hi John. One reason could be data. Abstract classes can hold data, interfaces can't. Antonio That's a reason to use an abstract class, not a reason to use an interface.
Re: How to run the dub bundle with dmd
On Saturday, 10 August 2019 at 13:46:23 UTC, Andre Pany wrote: On Saturday, 10 August 2019 at 13:18:19 UTC, greatsam4sure wrote: I came across the problem recently. I have dub 1.11.0 install on my windows 10 core i7 but does not support the command "dub add package name" since all the packages in dub package register now use this command. I cannot find window binary for the recent version of dub I have uninstalled the dub 1.11.0 on my machine, I have to use the one bundled with DMD 2.087.1. If I run dub -version, windows 10 throw an error that says " this app can run on this machine". I cannot also install DLS. This same error. I get this error from dlang related app such as dub,rdmd, Dls, etc. I will appreciate any help Can you make a screenshot of the popup? Kind regards Andre I have make a screenshot of the popup but I don't know to post here. Is there away to post a pix here
Re: How to run the dub bundle with dmd
On Saturday, 10 August 2019 at 13:18:19 UTC, greatsam4sure wrote: I came across the problem recently. I have dub 1.11.0 install on my windows 10 core i7 but does not support the command "dub add package name" since all the packages in dub package register now use this command. I cannot find window binary for the recent version of dub I have uninstalled the dub 1.11.0 on my machine, I have to use the one bundled with DMD 2.087.1. If I run dub -version, windows 10 throw an error that says " this app can run on this machine". I cannot also install DLS. This same error. I get this error from dlang related app such as dub,rdmd, Dls, etc. I will appreciate any help Can you make a screenshot of the popup? Kind regards Andre
Re: How to run the dub bundle with dmd
On Saturday, 10 August 2019 at 13:30:39 UTC, Dukc wrote: On Saturday, 10 August 2019 at 13:18:19 UTC, greatsam4sure wrote: I came across the problem recently. I have dub 1.11.0 install on my windows 10 core i7 but does not support the command "dub add package name" since all the packages in dub package register now use this command. I cannot find window binary for the recent version of dub What did you precisely write on the console, and what was the output? I have uninstalled the dub 1.11.0 on my machine, I have to use the one bundled with DMD 2.087.1. If I run dub -version, windows 10 throw an error that says " this app can run on this machine". That means that either you installed wrong dub (Linux version for example), or the executable file is corrupt. Download a new one. I am talking of the dub that is bundled with DMD 2.087.1 dmd is working fine but I can't use it dub
Re: How to run the dub bundle with dmd
On Saturday, 10 August 2019 at 13:18:19 UTC, greatsam4sure wrote: I came across the problem recently. I have dub 1.11.0 install on my windows 10 core i7 but does not support the command "dub add package name" since all the packages in dub package register now use this command. I cannot find window binary for the recent version of dub What did you precisely write on the console, and what was the output? I have uninstalled the dub 1.11.0 on my machine, I have to use the one bundled with DMD 2.087.1. If I run dub -version, windows 10 throw an error that says " this app can run on this machine". That means that either you installed wrong dub (linux version for example), or the executable file is corrupt. Download a new one.
How to run the dub bundle with dmd
I came across the problem recently. I have dub 1.11.0 install on my windows 10 core i7 but does not support the command "dub add package name" since all the packages in dub package register now use this command. I cannot find window binary for the recent version of dub I have uninstalled the dub 1.11.0 on my machine, I have to use the one bundled with DMD 2.087.1. If I run dub -version, windows 10 throw an error that says " this app can run on this machine". I cannot also install DLS. This same error. I get this error from dlang related app such as dub,rdmd, Dls, etc. I will appreciate any help
Re: LNK4255 warning - should I be concerned?
On Thursday, 8 August 2019 at 18:14:22 UTC, DanielG wrote: "warning LNK4255: library contain multiple objects of the same name; linking object as if no debug info" Is there some way to get more detail about this warning? Might help to know which objects ... My program is working fine now, but is this going to cause problems later on? Like when I want to debug? Let me guess, you're linking Vibe.D? I get those errors all the time while using it. Haven't noticed effect on behaviour but it might be related to why it won't compile as 32-bit.
Getting a HTTP request body over wire for Vibe.d to process
I am trying to use XMLHttpRequest[1] to send a request with a body for Vibe.D to process. However, it seems that I'm getting tripped up on serverside and client side api simultaenously, with no way to know what's really happening. I'm starting to be positive that I need a code example or I'll be trying to pass that HTTP body till Chrismas! Can anybody suggest an example, with both clientside and serverside code. I don't care anybody if the body is raw bytes or JSON, I just want to finally receive it. [1] https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/send
Re: Abstract classes vs interfaces, casting from void*
On Saturday, 10 August 2019 at 08:20:46 UTC, John Colvin wrote: On Friday, 9 August 2019 at 13:39:53 UTC, Simen Kjærås wrote: Thanks for the extra detail. Is there a solid reason to ever use an interface over an abstract class? (Other than multiple inheritance). I'm such a noob at anything related to OO. The general question is tricky, as different languages differ in details what is forced and what is allowed for abstract classes and interfaces. But roughly speaking, my opinion is: if you can/want to provide some default behavior than you are about to write an abstract class. If you are about to provide information/restriction of behavior, then this is more like an interface.
Re: Abstract classes vs interfaces, casting from void*
On Saturday, 10 August 2019 at 08:20:46 UTC, John Colvin wrote: On Friday, 9 August 2019 at 13:39:53 UTC, Simen Kjærås wrote: Thanks for the extra detail. Is there a solid reason to ever use an interface over an abstract class? (Other than multiple inheritance). I'm such a noob at anything related to OO. Hi John. One reason could be data. Abstract classes can hold data, interfaces can't. Antonio
Re: Abstract classes vs interfaces, casting from void*
On Friday, 9 August 2019 at 13:39:53 UTC, Simen Kjærås wrote: Thanks for the extra detail. Is there a solid reason to ever use an interface over an abstract class? (Other than multiple inheritance). I'm such a noob at anything related to OO.
Re: Abstract classes vs interfaces, casting from void*
On Friday, 9 August 2019 at 13:39:53 UTC, Simen Kjærås wrote:
We're getting into somewhat advanced topics now. This is
described in the Application Binary Interface page of the
documentation[0]. In short: classes and interfaces both use a
vtable[1] that holds pointers to each of their methods. When we
cast a class instance to an interface, the pointer is adjusted,
such that the interface's vtable is the first member. Casting
via `void*` bypasses this adjustment.
Using `__traits(classInstanceSize)`, we can see that `C` has a
size of 12 bytes, while `D` only is 8 bytes (24 and 16 on
64-bit). This corresponds to the extra interface vtable as
described above.
When we first cast to `void*`, no adjustment happens, because
we're not casting to an interface. When we later cast the
`void*` to an interface, again no adjustment happens - in this
case because the compiler doesn't know what we're casting from.
If we use `__traits(allMembers, C)`, we can figure out which
methods it actually has, and implement those with some extra
debug facilities (printf):
class C : I
{
override void foo() { writeln("hi"); }
override string toString() { writeln("toString");
return ""; }
override hash_t toHash() { debug printf("toHash");
return 0; }
override int opCmp(Object o) { writeln("opCmp"); return
0; }
override bool opEquals(Object o) { writeln("opEquals");
return false; }
}
If we substitute the above in your program, we see that the
`toString` method is the one being called. This is simply
because it's at the same location in the vtable as `foo` is in
`I`'s vtable.
When casting from a class to a superclass, no pointer
adjustment is needed, as the vtable location is the same for
both.
We can look closer at the vtable, and see that for a new
subclass, additional entries are simply appended at the end:
class C {
void foo() {}
}
class D : C {
void bar() {}
}
unittest {
import std.stdio;
C c = new C();
D d = new D();
writeln("Pointer to foo(): ", (&c.foo).funcptr);
writeln("Pointer to bar(): ", (&d.bar).funcptr);
writeln("Pointer to foo() in C's vtable: ", c.__vptr[5]);
writeln("Pointer to foo() in D's vtable: ", d.__vptr[5]);
writeln("Pointer to bar() in D's vtable: ", d.__vptr[6]);
}
As we see, `foo()` has the position in the vtable for both `c`
and `d`, while `D`'s new `bar()` method is added as the next
entry.
--
Simen
[0]: https://dlang.org/spec/abi.html
[1]: https://en.wikipedia.org/wiki/Virtual_method_table
Thanks for the extra detail.
Is there a solid reason to ever use an interface over an abstract
class? (Other than multiple inheritance).
I'm such a noob at anything related to OO.
