Re: Two questions
On Wednesday, 2 January 2019 at 17:49:52 UTC, H. S. Teoh wrote:
On Wed, Jan 02, 2019 at 05:38:41PM +, IM via
Digitalmars-d-learn wrote:
1- How do I do in D the equivalent of the following C++ macro?
#define OUT_VAL(val) (count << #val << " = " << val << endl)
In particular the #val above to the actual macro argument as a
string?
[...]
Try something along these lines:
import std.stdio;
void OUT_VAL(alias val)() {
writefln("%s = %s", __traits(identifier, val), val);
}
void main() {
int i = 123;
string s = "abc";
OUT_VAL!i;
OUT_VAL!s;
}
T
Thank you so much. Will give this a try.
Re: Two questions
On Wednesday, 2 January 2019 at 21:56:03 UTC, Steven
Schveighoffer wrote:
On 1/2/19 12:38 PM, IM wrote:
[...]
With those ... I have to guess.
There are 2 possibilities.
Possibility 1: there is a method named 'doSomeWork' which takes
at least one parameter. This overrides the UFCS function
(member functions always win over UFCS).
Possibility 2: All this is actually inside a function or
unittest. Nested functions cannot participate in UFCS.
Perfect, this was it. Thank you so much. doSomeWork() was nested
inside a unittest{} block. I didn't know UFCS won't work in this
case.
Of course, these are guesses. But given the very scant code
above, I'm not sure I could offer any other suggestions. If
neither of those is the case, I'd need a working example.
-Steve
Two questions
1- How do I do in D the equivalent of the following C++ macro?
#define OUT_VAL(val) (count << #val << " = " << val << endl)
In particular the #val above to the actual macro argument as a
string?
2- Yesterday I was experimenting with something and I wrote
something like the following:
struct MyType {
...
}
void doSomeWork(ref MyType o) {
...
}
auto t = MyType(...);
t.doSomeWork(); // <-- failed to compile.
Why did the above UFCS call fail to compile? I had to do
doSomeWork(t) instead.
Thank you so much!
Re: Noob question about structs allocation
On Monday, 15 October 2018 at 03:33:04 UTC, Basile B. wrote:
On Monday, 15 October 2018 at 03:19:07 UTC, IM wrote:
I probably used to know the answer to this question, but it's
been a long time since I last used D, and I don't remember.
Suppose we have:
struct S {
int num;
}
Would allocating an instance on the heap using:
S* s = new S;
use the GC, or do we have to call destroy() or delete on s
ourselves?
new is an operator that always allocates using the GC,
calling destroy yourself won't hurt either but is not necessary.
What is the effect of calling destroy?
- calling the destructor?
- deallocating the memory?
- both?
Noob question about structs allocation
I probably used to know the answer to this question, but it's
been a long time since I last used D, and I don't remember.
Suppose we have:
struct S {
int num;
}
Would allocating an instance on the heap using:
S* s = new S;
use the GC, or do we have to call destroy() or delete on s
ourselves?
Compiler gets confused with ambiguity when `int` matches both `real` and `float`.
The following expression: import std.math : sqrt; sqrt(400); produces the following compiler error: std.math.sqrt called with argument types (int) matches both: /usr/include/dmd/phobos/std/math.d(1592,7): std.math.sqrt(float x) and: /usr/include/dmd/phobos/std/math.d(1598,6): std.math.sqrt(real x) Shouldn't it just pick one according to some defined rules?
Re: Abstract Classes
On Wednesday, 6 December 2017 at 23:16:54 UTC, Ali Çehreli wrote: On 12/06/2017 03:01 PM, IM wrote: > On Wednesday, 6 December 2017 at 07:54:21 UTC, Ali Çehreli wrote: >> On 12/05/2017 11:23 PM, IM wrote: >>> [...] >> >> Just remove the override keywords in this case. No function is >> overriding any implementation here, they both implement an interface >> function. The fact that override can be used for A.foo can be seen as >> an inconsistency or a bug. >> >> Ali > > I believe this is a bug, and a confusing one to be honest. Can you > please help file one against the right owners? Thanks! There is no owners field when opening an issue. To get you started on the bug tracking system, please create this one yourself: :) https://issues.dlang.org/ Thank you, Ali Done: https://issues.dlang.org/show_bug.cgi?id=18041. Thanks!
Re: Abstract Classes
On Wednesday, 6 December 2017 at 07:54:21 UTC, Ali Çehreli wrote: On 12/05/2017 11:23 PM, IM wrote: [...] Just remove the override keywords in this case. No function is overriding any implementation here, they both implement an interface function. The fact that override can be used for A.foo can be seen as an inconsistency or a bug. Ali I believe this is a bug, and a confusing one to be honest. Can you please help file one against the right owners? Thanks!
Abstract Classes
Assume the following:
interface IFace {
void foo();
void bar();
}
abstract class A : IFace {
override void foo() {}
}
class B : A {
override void bar() {}
}
Now why this fails to compiler with the following message:
--->>>
function bar does not override any function, did you mean to
override 'IFace.bar()'?
<<<---
Obviously, I meant that, since the abstract class A implements
IFace, and B derives from A.
Do I need to declare IFace's unimplemented methods in A as
abstract? If yes, why? Isn't that already obvious enough (any
unimplemented virtual function is abstract)?
