Re: Issues using the in-line assembler
On Thursday, 5 April 2018 at 04:48:02 UTC, Basile B. wrote:
On Wednesday, 4 April 2018 at 21:00:44 UTC, solidstate1991
wrote:
void main()
{
import std.stdio;
(new Foo).foo(0,0).writeln;
}
```
Ah sorry, the params must be removed ((new Foo).foo().writeln;)...
I was actually trying to play with params and extern linkage to
see R11 always work...
Re: Issues using the in-line assembler
On Wednesday, 4 April 2018 at 21:00:44 UTC, solidstate1991 wrote:
I have this code:
asm @nogc{
movqXMM0, xy;
paddd XMM0, sXY; // xy + sXY
movqXMM3, xy0;
psubd XMM0, XMM3; // xy + sXY - x0y0
movqXMM1, ac;
movqXMM2, bd;
pmuludq XMM1, XMM0; // (ac * (xy + sXY - x0y0))
psrlq XMM1, 16; // (ac * (xy + sXY - x0y0))>>16
pmuludq XMM2, XMM0; // (bd * (xy + sXY - x0y0))
psrlq XMM2, 16; // (bd * (xy + sXY - x0y0))>>16
paddq XMM1, XMM2; // (bd * (xy + sXY - x0y0))>>16 * (ac * (xy
+ sXY - x0y0))>>16
punpckldq XMM3, XMM7;
paddq XMM1, XMM3; // (bd * (xy + sXY - x0y0))>>16 * (ac * (xy
+ sXY - x0y0))>>16 + x0y0
movups XMM2, XMM1; // Convert 64 bit vectors into 32 bit
ones
psrldq XMM2, 4;
por XMM2, XMM1;
movqresult, XMM2;
}
I'm getting "bad type/size of operand 'movq'" error on xy0, ac,
and bd when I try to compile it. All of the values are the type
of int[2], xy is function parameter, sXY is created locally.
How can I fix it?
The "this" seems to be in R11, so you have to apply the asm
syntax for accessing the members using
.offsetof.[R11], example:
```
class Foo
{
double a = 123456;
extern(D) double foo()
{
asm
{
naked;
movqXMM0, Foo.a.offsetof[R11];
ret;
}
}
}
void main()
{
import std.stdio;
(new Foo).foo(0,0).writeln;
}
```
However i cant find any specification saying that R11 is "this".
With a free function just pass the instance as param and replace
R11 by the register where the instance is passed.
Re: Construct immutable member in derived class
On Wednesday, April 04, 2018 21:46:13 Timoses via Digitalmars-d-learn wrote: > On Wednesday, 4 April 2018 at 18:11:12 UTC, Jonathan M Davis > > That code doesn't compile - at least not with dmd master. It > > gives these two errors: > > > > q.d(5): Error: constructor `q.A.this` missing initializer for > > immutable > > field i > > q.d(12): Error: cannot modify immutable expression this.i > > > > So, it's an error that the base class doesn't initialize the > > immutable member, and it's an error for the derived class to > > try to assign to it. > > I know, should have mentioned it. The question is why, however? > A rule like the above would force all derived classes to > initialize the immutable variable from the base class (if they > were allowed to). > Why aren't they? Because doing that basically makes it impossible to guarantee that the type system isn't violated. Once an immutable variable has been initialized, its value must _never_ change. It must be initalized exactly once, and the compiler doesn't necessarily have any clue what the base class constructors did or didn't do. There's no guarantee that it even has access to the function bodies for the base class when compiling the derived class. So, there is no way for it to safely put off the initialization of any base class members for the derived class to do. - Jonathan M Davis
Re: Declare and Define Before Use? [rant]
On Wednesday, 4 April 2018 at 20:01:55 UTC, Ali wrote:
On Wednesday, 4 April 2018 at 19:51:27 UTC, kdevel wrote:
On Wednesday, 4 April 2018 at 19:19:30 UTC, Ali wrote:
BTW: You can't write
void main ()
{
x.writeln;
int x;
}
import std.stdio;
This is because x is not module scope
you can do this
void main ()
{
x.writeln;
}
import std.stdio;
int x;
Cause there's no scope at the module level.
struct A
{
A* a;
~this()
{
// use a
}
}
void main()
{
A b = A();
A a; // in this case "a" destructed before "b", but "b" uses
"a"
}
Destruction and order of destruction becomes much more confusing.
You also can't do scope(exit) at the module level for a reason.
This mess shouldn't be allowed, it just makes it way worse to
understand what is going on.
Re: Better way to append to array than ~= ?
On Tuesday, 3 April 2018 at 19:02:25 UTC, Vladimirs Nordholm
wrote:
Hello people.
I currently have a function which multiple times per second
takes in arguments, and appends the argument as my special
type. The following code should explain what I do more properly:
struct MySpecialType { char c; }
auto foo(Args...)(Args args)
{
MySpecialType[] bar;
foreach(ref arg; args)
{
static if(is(typeof(arg) == MySpecialType))
{
bar ~= arg;
}
else
{
foreach(c; to!string(arg))
{
bar ~= MySpecialType(c);
}
}
}
// do more stuff
}
Now, from my trace.log, some of the topmost things on the
timing list are `std.array.Appender!(immutable(char).stuff>`. I also remember reading some years ago that ~= isn't
optimal for speed.
So my question is: Is there a better and/or faster way of doing
this, or is this the best approach?
I believe you are right to question the ~= in regards to
performance. So, what I would do is replace this loop:
foreach(c; to!string(arg))
{
bar ~= MySpecialType(c);
}
with this one liner:
bar ~= arg.map!(a => MySpecialType(a.to!char)).array;
To my mind, you replace multiple appends with just the one append
(to be fair, I don't know what the .array is doing internally,
but I'm sure whatever it does is nice and optimised).
Jordan
Re: Construct immutable member in derived class
On Wednesday, 4 April 2018 at 16:16:24 UTC, Alex wrote: Here is something: https://dlang.org/spec/class.html#constructors By the rules 7 and 8 it is suggested, what Simen already said, the construction of the base class can be independent from the derived one. And as such, the immutability has to handled in the constructor, next to the variable... "[...] the construction of the base class can be independent from the derived one." Hm, the points 7 and 8 don't clearly state what you wrote. But it somehow does make sense.. Still I wonder why that is so. Let's say you have an abstract class with immutable members. Why shouldn't derived class constructors be allowed to initialize these immutable members?
Re: Construct immutable member in derived class
On Wednesday, 4 April 2018 at 18:11:12 UTC, Jonathan M Davis
wrote:
On Wednesday, April 04, 2018 16:05:52 Timoses via
```
class A
{
immutable int i;
this(){}
}
class B : A
{
this()
{
this.i = 3;
super(); // <- specifically calling
//super constructor
afterwards
}
}
void main()
{
auto b = new B;
}
```
That code doesn't compile - at least not with dmd master. It
gives these two errors:
q.d(5): Error: constructor `q.A.this` missing initializer for
immutable
field i
q.d(12): Error: cannot modify immutable expression this.i
So, it's an error that the base class doesn't initialize the
immutable member, and it's an error for the derived class to
try to assign to it.
- Jonathan M Davis
I know, should have mentioned it. The question is why, however?
A rule like the above would force all derived classes to
initialize the immutable variable from the base class (if they
were allowed to).
Why aren't they?
Re: Issues using the in-line assembler
I forgot to tell, that xy0 ac, and bd are local to the class.
Issues using the in-line assembler
I have this code:
asm @nogc{
movqXMM0, xy;
paddd XMM0, sXY; // xy + sXY
movqXMM3, xy0;
psubd XMM0, XMM3; // xy + sXY - x0y0
movqXMM1, ac;
movqXMM2, bd;
pmuludq XMM1, XMM0; // (ac * (xy + sXY - x0y0))
psrlq XMM1, 16; // (ac * (xy + sXY - x0y0))>>16
pmuludq XMM2, XMM0; // (bd * (xy + sXY - x0y0))
psrlq XMM2, 16; // (bd * (xy + sXY - x0y0))>>16
paddq XMM1, XMM2; // (bd * (xy + sXY - x0y0))>>16 * (ac * (xy +
sXY - x0y0))>>16
punpckldq XMM3, XMM7;
paddq XMM1, XMM3; // (bd * (xy + sXY - x0y0))>>16 * (ac * (xy +
sXY - x0y0))>>16 + x0y0
movups XMM2, XMM1; // Convert 64 bit vectors into 32 bit
ones
psrldq XMM2, 4;
por XMM2, XMM1;
movqresult, XMM2;
}
I'm getting "bad type/size of operand 'movq'" error on xy0, ac,
and bd when I try to compile it. All of the values are the type
of int[2], xy is function parameter, sXY is created locally. How
can I fix it?
Re: Declare and Define Before Use? [rant]
On Wednesday, 4 April 2018 at 19:51:27 UTC, kdevel wrote:
On Wednesday, 4 April 2018 at 19:19:30 UTC, Ali wrote:
On Wednesday, 4 April 2018 at 18:57:27 UTC, kdevel wrote:
[...]
I think the rules should have been the same everywhere
and if there was an exception to be made, it could be made for
the main function
since the main function is special anyway
The main function of a program corresponds to the final
paragraph of a novel. I never understood why programmers place
this function which possibly depends on all other functions in
the translation unit at the beginning.
BTW: You can't write
void main ()
{
x.writeln;
int x;
}
import std.stdio;
There is no reason why the declaration of x should not be
postponed.
I've never seen the main function at the top but I think it would
be be nice place for it honnestly. Sounds more like a C legacy
than anything.
The reason why I place common imports at the top is because I
read a *lot* of code as my day job is to audit software. While
skimming rapidly through directories looking only at the top of
each file I know what they are about and can quickly infer their
purpose based solely on imports. This file does IO, this one web
stuff, etc (and to debunk quickly a counter argument I've heard
before: no, given how convoluted file names quickly get
especially in languages like java, directory structure isn't
nearly enough).
The same is true for the main function. If your code is clean it
should the main is the place where you orchestrate the whole
program. You should be able to grasp most of the program flow
from it. What it setups, information flow, etc. Of course in
practice people are often trying to burry useful information deep
down in functions (where it's generally too coupled for its own
good, but that's another story). Such burrying makes it harder to
get useful information from the main function, hence maybe why so
many are comfortable putting it at the end (I know I do by habit).
On the other hand, if the main effectively describes the programs
course then putting it at the beggining makes complete sense: it
is what you want to see first to get an idea of what the program
is doing. No function could be better suited for that.
Some points hinted here make me think of
https://www.youtube.com/watch?v=FyCYva9DhsI so maybe it could be
of some interest to you.
Re: Declare and Define Before Use? [rant]
On Wednesday, 4 April 2018 at 19:51:27 UTC, kdevel wrote:
On Wednesday, 4 April 2018 at 19:19:30 UTC, Ali wrote:
BTW: You can't write
void main ()
{
x.writeln;
int x;
}
import std.stdio;
This is because x is not module scope
you can do this
void main ()
{
x.writeln;
}
import std.stdio;
int x;
Re: how to set up libuid on wondows 10
On Wednesday, 4 April 2018 at 19:10:33 UTC, greatsam4sure wrote: I am have problem setting up libuid on windows 10. These are the errors thus far: [...] How do you call the compiler? Make sure you pass all the libraries etc. to dmd when you compile.
Re: Declare and Define Before Use? [rant]
On Wednesday, 4 April 2018 at 19:19:30 UTC, Ali wrote:
On Wednesday, 4 April 2018 at 18:57:27 UTC, kdevel wrote:
[...]
I think the rules should have been the same everywhere
and if there was an exception to be made, it could be made for
the main function
since the main function is special anyway
The main function of a program corresponds to the final paragraph
of a novel. I never understood why programmers place this
function which possibly depends on all other functions in the
translation unit at the beginning.
BTW: You can't write
void main ()
{
x.writeln;
int x;
}
import std.stdio;
There is no reason why the declaration of x should not be
postponed.
Re: Declare and Define Before Use? [rant]
On Wednesday, 4 April 2018 at 18:57:27 UTC, kdevel wrote:
Why are people writing
import std.stdio;
void main ()
{
}
struct S {
}
but not
void main ()
{
}
struct S {
}
import std.stdio;
?
Personally i found it weird and inconsistent that
you can import and define anywhere at module scope
but for any other scope you have to define and import before use
I think the rules should have been the same everywhere
and if there was an exception to be made, it could be made for
the main function
since the main function is special anyway
Personally I would either do
import
declare and define
main
or
main
import
declare and define
the later, is because main is special, so it is as if i am saying
this is what i want to do (main) and to do it (import) this stuff
and (declare and define this stuff) ... putting main first would
be just to highlight it and attract attention to it
importing and declaring anywhere at module scope is just too
random for my taste
how to set up libuid on wondows 10
I am have problem setting up libuid on windows 10. These are the errors thus far: C:\Users\Greatsam\Desktop\HelloApp>dub Fetching libuid 0.0.7 (getting selected version)... Performing "debug" build using dmd for x86. libuid 0.0.7: building configuration "lib"... helloapp ~master: building configuration "application"... Linking... OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(App) Error 42: Symbol Undefined _uiControlDestroy ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(App) Error 42: Symbol Undefined _uiMain ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowTitle ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowSetTitle ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowPosition ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowSetPosition ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowCenter ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowContentSize ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowSetContentSize ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowFullscreen ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowSetFullscreen ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowBorderless ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowSetBorderless ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowSetChild ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowMargined ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowSetMargined ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiOpenFile ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiSaveFile ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiMsgBox ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiMsgBoxError ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiNewWindow ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowOnPositionChanged ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowOnContentSizeChanged
Declare and Define Before Use? [rant]
Why are people writing
import std.stdio;
void main ()
{
S s;
s.foo;
}
struct S {
void foo ()
{
writeln ("a");
}
}
but not
void main ()
{
S s;
s.foo;
}
struct S {
void foo ()
{
writeln ("a");
}
}
import std.stdio;
?
Re: Optional parameters?
On Wednesday, 4 April 2018 at 15:44:34 UTC, Steven Schveighoffer
wrote:
See my original post:
I know I can do things like this:
void foo(int x) { return foo(nullable(x)); }
-Steve
Oops, I read only the body of that function and thought it's a
main function constructiong nullable when calling.
Well, short of defining some sort of mixin to do this
automatically, no better ideas :(.
Re: Construct immutable member in derived class
On Wednesday, April 04, 2018 16:05:52 Timoses via Digitalmars-d-learn wrote:
> On Wednesday, 4 April 2018 at 10:41:52 UTC, Simen Kjærås wrote:
> > Because by the time B's constructor is called, A might already
> > have initialized it, and rely on it never changing.
>
> What about:
>
> ```
> class A
> {
> immutable int i;
>
> this(){}
> }
>
> class B : A
> {
> this()
> {
> this.i = 3;
> super(); // <- specifically calling
>//super constructor afterwards
> }
> }
>
> void main()
> {
> auto b = new B;
> }
> ```
That code doesn't compile - at least not with dmd master. It gives these two
errors:
q.d(5): Error: constructor `q.A.this` missing initializer for immutable
field i
q.d(12): Error: cannot modify immutable expression this.i
So, it's an error that the base class doesn't initialize the immutable
member, and it's an error for the derived class to try to assign to it.
- Jonathan M Davis
Re: Construct immutable member in derived class
On Wednesday, 4 April 2018 at 16:05:52 UTC, Timoses wrote: This becomes a bit hideous, unfortunately, when there are many initializations involved. Found this, but it doesn't mention anything about derived classes.. https://dlang.org/spec/class.html#field-init Here is something: https://dlang.org/spec/class.html#constructors By the rules 7 and 8 it is suggested, what Simen already said, the construction of the base class can be independent from the derived one. And as such, the immutability has to handled in the constructor, next to the variable...
Re: Construct immutable member in derived class
On Wednesday, 4 April 2018 at 10:41:52 UTC, Simen Kjærås wrote:
Because by the time B's constructor is called, A might already
have initialized it, and rely on it never changing.
What about:
```
class A
{
immutable int i;
this(){}
}
class B : A
{
this()
{
this.i = 3;
super(); // <- specifically calling
//super constructor afterwards
}
}
void main()
{
auto b = new B;
}
```
Same result
The solution is to add a constructor overload to A, and call
that from B:
class A
{
immutable int i;
protected this(int i) {
this.i = i;
}
}
class B : A
{
this()
{
super(3);
}
}
unittest
{
auto b = new B;
}
--
Simen
This becomes a bit hideous, unfortunately, when there are many
initializations involved.
Found this, but it doesn't mention anything about derived
classes..
https://dlang.org/spec/class.html#field-init
Re: Get the type of 'alias this ='
On Wednesday, 4 April 2018 at 15:57:19 UTC, Simen Kjærås wrote: On Wednesday, 4 April 2018 at 15:49:31 UTC, Vladimirs Nordholm wrote: if (is(T == A) || is(T == B) || is(T == Enum)) if (is(T : Enum)) -- Simen Ah! Thanks a lot!
Re: Get the type of 'alias this ='
On Wednesday, 4 April 2018 at 15:49:31 UTC, Vladimirs Nordholm
wrote:
private template Mix()
{
this(Enum ee) { e = ee; }
Enum e;
alias this = e;
}
Oops, typo in the alias. Should be `alias e this`
Re: Get the type of 'alias this ='
On Wednesday, 4 April 2018 at 15:49:31 UTC, Vladimirs Nordholm wrote: if (is(T == A) || is(T == B) || is(T == Enum)) if (is(T : Enum)) -- Simen
Re: Better way to append to array than ~= ?
On Tuesday, 3 April 2018 at 20:41:01 UTC, Alex wrote:
On Tuesday, 3 April 2018 at 20:02:46 UTC, Vladimirs Nordholm
wrote:
On Tuesday, 3 April 2018 at 19:53:11 UTC, Meta wrote:
[...]
I don't think I know the size of the arguments.
If I pass in "123" and MySpecialType('a'), the result should
be:
assert(foo("123", MySpecialType('a')) ==
[MySpecialType('1'), MySpecialType('2'), MySpecialType('3'),
MySpecialType('a')]);
What should the length of the pre-allocated array be?
In my try, I iterate the args twice. The first time to
calculate the number of elements, then preallocate and then
iterate them again and constructing the proper objects.
It is not nice, but about 1/3 of time, compared to original
version, compiled in release mode.
https://run.dlang.io/is/E6ckog
Yeah, I will probably need to iterate twice.
Thanks a bunch
Get the type of 'alias this ='
Hello people from D-land.
Short question: Can get the type of a struct that has `alias this
= ` ?
See this example, where a struct is aliased to an enum:
enum Enum { one, two, three, fourtytwo }
private template Mix()
{
this(Enum ee) { e = ee; }
Enum e;
alias this = e;
}
struct A { mixin Mix }
struct B { mixin Mix }
T foo(T) (T f) if (is(T == A) || is(T == B) || is(T == Enum))
// |--|
// ^ I want to change this into
something more nice looking
{
// ...
}
I want to check the type in a more 'cleaner' way.
Best regards,
Vladimirs Nordholm
Re: Optional parameters?
On 4/4/18 8:59 AM, Dukc wrote:
Is this what you're looking for?
See my original post:
I know I can do things like this:
void foo(int x) { return foo(nullable(x)); }
-Steve
Re: Taming templates and mixin magic: type inpector helper in D/Phobos?
On Wednesday, 4 April 2018 at 05:28:57 UTC, Carlos Navarro wrote: As a newbie in D (and making a lots of mistakes), I've found myself relying heavily in the use of a rudimentary type inspector to visualize my templated code instantiations. It's simple and incomplete as hell but good enough to see what happens under the hood quickly. QUESTION: Is there a function like that already in D? //real-life example goodEnoughTypeInspector!Human; goodEnoughTypeInspector!(Database!Human); //compile-time output Inspecting type: Human - public string name - public string address - public bool active Inspecting type: Database!(Human) - private string[] name - private string[] address - private bool[] active - public pure nothrow @nogc @safe ulong() count - public void insert you might want to check std.traits [0] and __traits [1]. They both contain functions that may be useful. To get members you could use __traits(allMembers, MyTemplate!SomeType); Just check through the docs for relevant functions. You can then compose the relevant function. I wrote a basic version you can play with [2]. [0]: https://dlang.org/phobos/std_traits.html [1]: https://dlang.org/spec/traits.html [2]: https://run.dlang.io/is/COZ89T
Re: Optional parameters?
On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer
wrote:
But I'd rather avoid such things if possible. Is there a way
around this? Seems rather limiting that I can do:
Is this what you're looking for?
void foo(Nullable!int x = Nullable!int.init)
{ if (!x.isNull) x.get.writeln;
else writeln;
}
void foo(int x)
{ return Nullable!int(x).foo;
}
void main()
{
foo(1); // 1
int x;
foo(x++); // 0
foo; // empty line
foo(x); // 1
readln();
}
Re: Strange behavior using array of structures
On Wednesday, 4 April 2018 at 10:09:41 UTC, sarn wrote:
On Wednesday, 4 April 2018 at 10:00:18 UTC, Orfeo wrote:
foreach (l; log) {
l.run;
}
Try making this "foreach (ref l; log) {".
Structs are value types in D, so by default they're copied when
you assign them to another variable (in this case l). That
means run() is modifying a copy that gets thrown away each
time. "ref l" makes l into a reference to the original struct
instance.
Great!! thank you very much
Re: Construct immutable member in derived class
On Wednesday, 4 April 2018 at 10:11:37 UTC, Timoses wrote:
Example:
```
class A
{
immutable int i;
this(){}
}
class B : A
{
this()
{
this.i = 3;
}
}
void main()
{
auto b = new B;
}
```
throws:
Error: constructor `onlineapp.A.this` missing initializer for
immutable field i
Error: cannot modify immutable expression this.i
Why can't I initialize the immutable member in the derived
class?
Because by the time B's constructor is called, A might already
have initialized it, and rely on it never changing. The solution
is to add a constructor overload to A, and call that from B:
class A
{
immutable int i;
protected this(int i) {
this.i = i;
}
}
class B : A
{
this()
{
super(3);
}
}
unittest
{
auto b = new B;
}
--
Simen
Construct immutable member in derived class
Example:
```
class A
{
immutable int i;
this(){}
}
class B : A
{
this()
{
this.i = 3;
}
}
void main()
{
auto b = new B;
}
```
throws:
Error: constructor `onlineapp.A.this` missing initializer for
immutable field i
Error: cannot modify immutable expression this.i
Why can't I initialize the immutable member in the derived class?
Re: Strange behavior using array of structures
On Wednesday, 4 April 2018 at 10:00:18 UTC, Orfeo wrote:
foreach (l; log) {
l.run;
}
Try making this "foreach (ref l; log) {".
Structs are value types in D, so by default they're copied when
you assign them to another variable (in this case l). That means
run() is modifying a copy that gets thrown away each time. "ref
l" makes l into a reference to the original struct instance.
Strange behavior using array of structures
Hi all,
I have:
```
import std.stdio;
void main() {
Logger[] log;
Logger l0 = Logger(0,1);
Logger l1 = Logger(100,1);
Logger l2 = Logger(200,1);
log ~= l0;
log ~= l1;
foreach (i; 0 .. 3) {
writeln("it:", i);
foreach (l; log) {
l.run;
}
}
}
struct Logger {
int initial;
int increment;
void run() {
initial += increment;
writeln("\t", initial);
}
}
```
Output:
```
it:0
1
101
it:1
1
101
it:2
1
101
```
If I use:
```
void main() {
Logger[] log;
Logger l0 = Logger(0,1);
Logger l1 = Logger(100,1);
Logger l2 = Logger(200,1);
log ~= l0;
log ~= l1;
foreach (i; 0 .. 3) {
writeln("it:", i);
l0.run();
l1.run();
}
}
```
output (correct) is:
```
it:0
1
101
it:1
2
102
it:2
3
103
```
can someone help me to understand? Thanks!
Re: Optional parameters?
On Wednesday, 4 April 2018 at 08:08:40 UTC, Dejan Lekic wrote: On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer wrote: I currently have a situation where I want to have a function that accepts a parameter optionally. This is what function overloading and/or default values are for, right? Not if you'd like to pass an actual _optional_ parameter for e.g. an int. Default parameter would actually assign a value. See also: https://forum.dlang.org/post/rzgcenuqiokknpslt...@forum.dlang.org
Re: Optional parameters?
On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer wrote: I currently have a situation where I want to have a function that accepts a parameter optionally. This is what function overloading and/or default values are for, right?
