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 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 ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084
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?