Re: Getting the parameters and other attributes belonging to the function overload with the greatest number of arguments
On Tuesday, 31 May 2016 at 20:46:37 UTC, Basile B. wrote: Yes this can be done, you must use the getOverload trait: https://dlang.org/spec/traits.html#getOverloads The result of this trait is the function itself so it's not hard to use, e.g the result can be passed directly to 'Parameters', 'ReturnType' and such library traits. Awesome, thank you!
Re: Is there any overhead iterating over a pointer using a slice?
On Tuesday, 31 May 2016 at 18:55:18 UTC, Gary Willoughby wrote: If I have a pointer and iterate over it using a slice, like this: T* foo = &data; foreach (element; foo[0 .. length]) { ... } Is there any overhead compared with pointer arithmetic in a for loop? Use the assembly output of your compiler to check! :-) It's fun to look at. For example, with GDC: http://goo.gl/Ur9Srv No difference. cheers, Johan
Re: Getting the parameters and other attributes belonging to the function overload with the greatest number of arguments
On Tuesday, 31 May 2016 at 20:06:47 UTC, pineapple wrote: I'd like to find the overload of some function with the most parameters and (in this specific case) to get their identifiers using e.g. ParameterIdentifierTuple. There have also been cases where I'd have liked to iterate over the result of Parameters!func for each overload of that function. Can this be done, and if so how? Yes this can be done, you must use the getOverload trait: https://dlang.org/spec/traits.html#getOverloads The result of this trait is the function itself so it's not hard to use, e.g the result can be passed directly to 'Parameters', 'ReturnType' and such library traits.
Re: asm woes...
On Tuesday, 31 May 2016 at 18:52:16 UTC, Marco Leise wrote: The 'this' pointer is usually in some register already. On Linux 32-bit for example it is in EAX, on Linux 64-bit is in RDI. The AX register seems like a bad choice, since you require the AX/DX registers when you do multiplication and division (although all other registers are general purpose some instructions are still tied to specific registers). SI/DI are a much better choice. By the way, you are right that 32-bit does not have access to 64-bit machine words (actually kind of obvious), but your idea wasn't far fetched, since there is the X32 architecture at least for Linux. It uses 64-bit machine words, but 32-bit pointers and allows for compact and fast programs. As i recall the switch to use the larger registers is a simple switch per instruction, something like either 60h, 66h or 67h. I forget which one exactly, as i recall writing assembly programs using 16bit DOS but using 32bit registers using that trick (built into the assembler). Although to use the lower registers by themselves required the same switch, so...
Getting the parameters and other attributes belonging to the function overload with the greatest number of arguments
I'd like to find the overload of some function with the most parameters and (in this specific case) to get their identifiers using e.g. ParameterIdentifierTuple. There have also been cases where I'd have liked to iterate over the result of Parameters!func for each overload of that function. Can this be done, and if so how?
Is there any overhead iterating over a pointer using a slice?
In relation to this thread: http://forum.dlang.org/thread/ddckhvcxlyuvuiyaz...@forum.dlang.org Where I asked about slicing a pointer, I have another question: If I have a pointer and iterate over it using a slice, like this: T* foo = &data; foreach (element; foo[0 .. length]) { ... } Is there any overhead compared with pointer arithmetic in a for loop?
Re: Is there any overhead iterating over a pointer using a slice?
On Tuesday, 31 May 2016 at 18:55:18 UTC, Gary Willoughby wrote: Is there any overhead compared with pointer arithmetic in a for loop? Very very little. The slice will ensure start and stop indexes are in bounds before the loop (and throw an RangeError if it isn't), but inside the loop, it should generate exactly the same code.
Re: asm woes...
Am Fri, 27 May 2016 10:16:48 + schrieb Era Scarecrow : > On Friday, 27 May 2016 at 10:14:31 UTC, Era Scarecrow wrote: > > inc dword ptr [EAX+Foo.x.offsetof]; > > > So just tested it, and it didn't hang, meaning all unittests > also passed. > > Final solution is: > >asm pure @nogc nothrow { > mov EAX, this; > add dword ptr [EAX+wideIntImpl.lo.offsetof], 1; > adc dword ptr [EAX+wideIntImpl.lo.offsetof+4], 0; > adc dword ptr [EAX+wideIntImpl.hi.offsetof], 0; > adc dword ptr [EAX+wideIntImpl.hi.offsetof+4], 0; >} The 'this' pointer is usually in some register already. On Linux 32-bit for example it is in EAX, on Linux 64-bit is in RDI. What DMD does when it encounters an asm block is, it stores every parameter (including the implicit this) on the stack and when you do "mov EAX, this;" it loads it back from there using EBP as the base pointer to the stack variables. The boilerplate will look like this on 32-bit Linux: push EBP // Save what's currently in EBP movEBP,ESP // Remember current stack pointer as base for variables push EAX // Save implicit 'this' parameter on the stack movEAX,DWORD PTR [EBP-0x4] // Load 'this' into EAX as you requested movESP,EBP // Restore stack to what it was before saving parameters and variables popEBP // Restore EBP register ret// Return from function Remember that this works only for x86 32-bit in DMD and LDC. GDC passes inline asm right through to an arbitrary external assembler after doing some template replacements. It will not understand any of the asm you feed it, but forward the external assemblers error messages. On the other hand GDC's and LDC's extended assemblers free you from manually loading stuff into registers. You just use a placeholder and tell the compiler to put 'this' into some register. The compiler will realize it is already in EAX or RDI and do nothing but use that register instead of EAX in your code above. Sometimes that has the additional benefit that the same asm code works on both 32-bit and 64-bit. Also, extended asm is transparent to the optimizer. The code can be inlined and already loaded variables reused. By the way, you are right that 32-bit does not have access to 64-bit machine words (actually kind of obvious), but your idea wasn't far fetched, since there is the X32 architecture at least for Linux. It uses 64-bit machine words, but 32-bit pointers and allows for compact and fast programs. -- Marco
Re: asm woes...
Am Fri, 27 May 2016 10:06:28 + schrieb Guillaume Piolat : > Referencing EBP or ESP yourself is indeed dangerous. Not sure why > the documentation would advise that. Using "this", names of > parameters/locals/field offset is much safer. DMD makes sure that the EBP relative access of parameters and stack variables works by copying everything to the stack that's in registers when you have an asm block in the function. Using var[EBP] or just plain var will then dereference that memory location. -- Marco
Re: Why simple code using Rebindable doesn't compile ?
On Tuesday, 31 May 2016 at 06:40:31 UTC, Era Scarecrow wrote: On Tuesday, 31 May 2016 at 05:31:59 UTC, chmike wrote: My conclusion is that rebindable is not a satisfying solution to have mutable references to immutable objects. I don't understand the rationale of these immutable references. It is too constraining. I still don't know why you're trying to use immutable. In the other thread you have listed you are trying to make a global singleton? You needed it mutable but marked immutable (for... some reason?) but all the methods won't change the contents or spirit of the object. I need to wrap my head around what you're trying to do before i can suggest anything else. Although making all members private and all functions as const would give you a mutable/unchanging object... The code I gave are just examples. The reason I used immutable is because I have two types of objects. I have many Info objects (~150) which are all singletons. These Info objects have a reference to a Category objects which is also a singleton. I can have mutable singleton objects. I have a public interface that doesn't allow to modify the object. This is not the problem. The problem is that I would like that all these objects are instantiated at compile time. This is to keep the start of the program fast. There is no problem to instantiate the Category object at compile time. The problem is to instantiate the different Info objects at compile time that have a reference to the Category object. Ctfe doesn't work when a global variable is referenced. I noticed that it worked when the Category is declared immutable. I can add a reference to that Category singleton instance to the new call of the Info objects. So the goal is to create and interconnect multiple objects at compile time. Ideally I would need to store a reference to each of the Info objects in an associative array so that I can retrieve a reference to it with some key.
Re: D, GTK, Qt, wx,…
On Tuesday, 31 May 2016 at 08:57:51 UTC, MGW wrote: QtE5 - is my wrapper for Qt-5 https://www.youtube.com/watch?v=DuOl-4g117E https://github.com/MGWL/QtE5 How can we build QtE5 and/or the examples?
Re: Operator overloading through UFCS doesn't work
On Tuesday, May 31, 2016 14:11:58 ixid via Digitalmars-d-learn wrote: > On Sunday, 29 May 2016 at 07:18:10 UTC, Jonathan M Davis wrote: > > And the fact that allowing free functions to overload operators > > via UFCS sends us into that territory just highlights the fact > > that they're a horrible idea. > > > > - Jonathan M Davis > > Do you have any examples of UFCS doing bad things? Most people > seem to very much like it yet you argue against any change that > would benefit UFCS. > > You seem to prefer: > > read(to(easier(much(i over i.much.easier.to.read The primary benefit of UFCS is that you can write generic code that will work with both member functions and free functions, allowing you to have a free function that does something and a member function that does that same thing more efficiently for that specific type (a prime example of this would be a function like find where a linear search make sense in most cases but wouldn't for certain data structures - e.g. a sorted, binary tree). So, the "universal" aspect of UFCS is important for generic code, whereas it would be completely unnecessary if the code weren't generic. All of the other benefits of UFCS are highly subjective and have to do with what a particular person thinks is easier or harder to read rather than actual, technical benefits (though obviously writing code in a way that is easier to read for those working on it is obviously valuable). Personally, I've dealt with functional languages enough that I've never felt that UFCS was much of an improvement syntactically. But we have it, and anyone is free to use it or not as they see fit. Regardless, what I'm arguing against here is altering operator overloading so that it works with free functions via UFCS instead of requiring that it be part of the type. It's a terrible idea IMHO to allow random code to add an overloaded operator to a type rather having it actually be part of the type's design, and in addition to that, it doesn't play at all nicely with symbol conflicts, because you're using an operator rather than a function, meaning that not only do you have no way to specify which version of the overloaded operator code should use, but it would completely defeat the purpose of using an overloaded operator in the first place even if you could. But fortunately, Walter agrees with me (or at least did, the last time the subject came up in the newsgroup), so I don't think that I have to worry about overloaded operators be definable via free functions. - Jonathan M Davis
Re: Why aren't overloaded nested functions allowed?
On Tuesday, 31 May 2016 at 11:54:40 UTC, Timon Gehr wrote: On 30.05.2016 18:22, Max Samukha wrote: From the spec (https://dlang.org/spec/function.html#nested): "Nested functions cannot be overloaded." Anybody knows what's the rationale? The rationale is that nobody has implemented it in DMD. https://issues.dlang.org/show_bug.cgi?id=12578 Ah, that "seems pointless" argument again.
Re: Operator overloading through UFCS doesn't work
On Sunday, 29 May 2016 at 07:18:10 UTC, Jonathan M Davis wrote: And the fact that allowing free functions to overload operators via UFCS sends us into that territory just highlights the fact that they're a horrible idea. - Jonathan M Davis Do you have any examples of UFCS doing bad things? Most people seem to very much like it yet you argue against any change that would benefit UFCS. You seem to prefer: read(to(easier(much(i over i.much.easier.to.read
Re: Why aren't overloaded nested functions allowed?
On 30.05.2016 18:22, Max Samukha wrote: From the spec (https://dlang.org/spec/function.html#nested): "Nested functions cannot be overloaded." Anybody knows what's the rationale? The rationale is that nobody has implemented it in DMD. https://issues.dlang.org/show_bug.cgi?id=12578
Re: Why do some T.init evaluate to true while others to false?
On Monday, 30 May 2016 at 19:06:53 UTC, ArturG wrote: does this count? struct Foo { int x; float f; } void main() { Foo foo; if(foo is typeof(foo).init) "A: does'nt work".writeln; foo = Foo(); if(foo is typeof(foo).init) "B: works".writeln; } This one is a bug in DMD. It works correctly with LDC. `Foo()` is supposed to be identical to `Foo.init`. File here: https://issues.dlang.org/show_bug.cgi?id=16105
Re: D, GTK, Qt, wx,…
On Sunday, 29 May 2016 at 11:03:36 UTC, Russel Winder wrote: GKT+ has a reputation for being dreadful on OSX and even worse on Windows. Qt on the other hand has a reputation for being the most portable – though clearly wx is (arguable) the most portable. QtE5 - is my wrapper for Qt-5 https://www.youtube.com/watch?v=DuOl-4g117E https://github.com/MGWL/QtE5
Re: @trusting generic functions
On Sunday, 29 May 2016 at 18:02:53 UTC, Steven Schveighoffer wrote: You can create a trusted expression by using a lambda and immediately calling it. ag0aep6g brought it up. I would write it like this (untested, but I think this works): return (()@trusted => &t)().doSomething(); The key is to limit your code that is tainted by @trusted to as little code as possible. This does indeed solve the problem without replicating code and costraints. It allows to just trust the parts of the function that can be trusted. Thank you very much. Lodovico Giaretta