Re: Getting the parameters and other attributes belonging to the function overload with the greatest number of arguments

[pineapple via Digitalmars-d-learn]

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?

[Johan Engelen via Digitalmars-d-learn]

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 = 

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

[Basile B. via Digitalmars-d-learn]

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...

[Era Scarecrow via Digitalmars-d-learn]

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

[pineapple via Digitalmars-d-learn]

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?

[Gary Willoughby via Digitalmars-d-learn]

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 = 

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?

[Adam D. Ruppe via Digitalmars-d-learn]

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...

[Marco Leise via Digitalmars-d-learn]

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...

[Marco Leise via Digitalmars-d-learn]

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 ?

[chmike via Digitalmars-d-learn]

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,…

[albatroz via Digitalmars-d-learn]

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

[Jonathan M Davis via Digitalmars-d-learn]

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?

[Max Samukha via Digitalmars-d-learn]

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

[ixid via Digitalmars-d-learn]

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?

[Timon Gehr via Digitalmars-d-learn]

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?

[Marc Schütz via Digitalmars-d-learn]

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,…

[MGW via Digitalmars-d-learn]

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

[Lodovico Giaretta via Digitalmars-d-learn]

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 => )().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

Re: Why aren't overloaded nested functions allowed?

[Max Samukha via Digitalmars-d-learn]

On Monday, 30 May 2016 at 23:17:15 UTC, pineapple wrote:

On Monday, 30 May 2016 at 16:22:26 UTC, Max Samukha wrote:
From the spec (https://dlang.org/spec/function.html#nested): 
"Nested functions cannot be overloaded."


Anybody knows what's the rationale?


I'm guessing it's related to -

Unlike module level declarations, declarations within function 
scope are processed in order.


And I'd suspect that the cleanest solution would be similar to 
the one given for interdependent functions: Declare the nested 
functions in a static nested struct instead.


Ok, thanks.

Re: Why simple code using Rebindable doesn't compile ?

[Era Scarecrow via Digitalmars-d-learn]

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...