On Friday, 11 September 2015 at 00:37:35 UTC, data man wrote:
On Thursday, 10 September 2015 at 16:24:52 UTC, Vladimir
Panteleev wrote:
...
Heh. My fault. Fixed (though it'll stick for that post in some
views).
Correct a "D-Runtime" topic, please. It is not updated.
Not sure what you mean,
On Thursday, 10 September 2015 at 16:24:52 UTC, Vladimir
Panteleev wrote:
...
Heh. My fault. Fixed (though it'll stick for that post in some
views).
Correct a "D-Runtime" topic, please. It is not updated.
On Thursday, 10 September 2015 at 21:29:15 UTC, Vladimir
Panteleev wrote:
Doesn't happen here, so that's something local to you, almost
surely unrelated to the above. Try clearing your cookies.
Yes, it was caused by cookies, but it wasn't local since it
returned a HTTP status 500. It happend o
On Thursday, 10 September 2015 at 21:24:17 UTC, Ola Fosheim
Grøstad wrote:
On Thursday, 10 September 2015 at 20:15:15 UTC, Vladimir
Panteleev wrote:
On Thursday, 10 September 2015 at 19:40:02 UTC, Ola Fosheim
Grøstad wrote:
On Thursday, 10 September 2015 at 16:24:52 UTC, Vladimir
Panteleev wrot
On Thursday, 10 September 2015 at 20:15:15 UTC, Vladimir
Panteleev wrote:
On Thursday, 10 September 2015 at 19:40:02 UTC, Ola Fosheim
Grøstad wrote:
On Thursday, 10 September 2015 at 16:24:52 UTC, Vladimir
Panteleev wrote:
Heh. My fault. Fixed (though it'll stick for that post in
some views).
On Thursday, 10 September 2015 at 19:40:02 UTC, Ola Fosheim
Grøstad wrote:
On Thursday, 10 September 2015 at 16:24:52 UTC, Vladimir
Panteleev wrote:
Heh. My fault. Fixed (though it'll stick for that post in some
views).
Now the main index says: "Unexpected end of input when
converting from ty
On Thursday, 10 September 2015 at 16:24:52 UTC, Vladimir
Panteleev wrote:
Heh. My fault. Fixed (though it'll stick for that post in some
views).
Now the main index says: "Unexpected end of input when converting
from type string to type long".
On Thursday, 10 September 2015 at 16:18:13 UTC, John Colvin wrote:
On Thursday, 10 September 2015 at 01:52:17 UTC, digitalmars.D
wrote:
On 10 September 2015 at 04:55, Walter Bright via Digitalmars-d
wrote:
On 6/10/2013 7:33 AM, Manu wrote:
[...]
Sorry to say, your n.g. poster is back to i
On Thursday, 10 September 2015 at 01:52:17 UTC, digitalmars.D
wrote:
On 10 September 2015 at 04:55, Walter Bright via Digitalmars-d
wrote:
On 6/10/2013 7:33 AM, Manu wrote:
[...]
Sorry to say, your n.g. poster is back to its old tricks :-)
We've resolved this issue since 6/10/2013 no? ;)
On 9/9/2015 6:52 PM, Manu via Digitalmars-d wrote:
We've resolved this issue since 6/10/2013 no? ;)
:-)
On 10 September 2015 at 04:55, Walter Bright via Digitalmars-d
wrote:
> On 6/10/2013 7:33 AM, Manu wrote:
>>
>> [...]
>
>
> Sorry to say, your n.g. poster is back to its old tricks :-)
We've resolved this issue since 6/10/2013 no? ;)
On Wednesday, 9 September 2015 at 18:33:41 UTC, Prudence wrote:
On Tuesday, 27 May 2014 at 12:21:40 UTC, d coder wrote:
[...]
What's the current state of this? I'm in need of such behavior
for win32 interop.
I'm thinking that one can make the above code more general by
using it in a mixin
On 9/9/2015 1:17 PM, Freddy wrote:
On Wednesday, 9 September 2015 at 18:55:18 UTC, Walter Bright wrote:
On 6/10/2013 7:33 AM, Manu wrote:
[...]
Sorry to say, your n.g. poster is back to its old tricks :-)
On 6/10/2013
That was 2 years ago.
Woops! I didn't notice. My reader sorts things ba
On Wednesday, 9 September 2015 at 20:18:06 UTC, Freddy wrote:
enum MemberFunc(alias Type, string member) = (ref Type self,
Parameters!(__traits(getMember, Type, member)) args) =>
mixin(q{self.} ~ member ~ q{(args)});
Whoops the alias wasn't needed
enum MemberFunc(Type, string member) = (ref T
On Wednesday, 9 September 2015 at 18:50:45 UTC, Walter Bright
wrote:
On 6/7/2013 4:21 PM, Manu wrote:
So from my dconf talk, I detailed a nasty hack to handle
member function
pointers in D.
https://www.digitalmars.com/articles/b68.html
Here's on automatic version
import std.t
On Wednesday, 9 September 2015 at 18:55:18 UTC, Walter Bright
wrote:
On 6/10/2013 7:33 AM, Manu wrote:
[...]
Sorry to say, your n.g. poster is back to its old tricks :-)
On 6/10/2013
That was 2 years ago.
On 6/10/2013 7:33 AM, Manu wrote:
[...]
Sorry to say, your n.g. poster is back to its old tricks :-)
On 6/7/2013 4:21 PM, Manu wrote:
So from my dconf talk, I detailed a nasty hack to handle member function
pointers in D.
https://www.digitalmars.com/articles/b68.html
On Tuesday, 27 May 2014 at 12:21:40 UTC, d coder wrote:
https://github.com/D-Programming-Language/dmd/pull/3181
Daniel asked me to use this. And it works.
Use something like:
union U
{
void delegate(int) dg;
struct
{
void* ptr;
void function(int) funcptr;
}
}
U u;
u.dg = dg;
u.
https://github.com/D-Programming-Language/dmd/pull/3181
Daniel asked me to use this. And it works.
Use something like:
union U
{
void delegate(int) dg;
struct
{
void* ptr;
void function(int) funcptr;
}
}
U u;
u.dg = dg;
u.funcptr = ...;
u.ptr = ...;
Regards
- Puneet
On Mon, Jun 10, 2013 at 10:13 PM, Jacob Carlborg wrote:
> On 2013-06-10 18:34, Manu wrote:
>
>> On 11 June 2013 02:26, Jacob Carlborg mailto:d...@me.com>>
>>
>> wrote:
>>
>> On 2013-06-10 17:40, David Nadlinger wrote:
>>
>> Let me try to summarize it in code:
>>
>> ---
>>
"Michel Fortin" wrote in message
news:kp4nr0$q71$1...@digitalmars.com...
>
> I just find it sad that we have to use a different calling convention for
> member functions. I mean, it'd be much more elegant be if a member
> function could simply be called from a "void function(Object)" by
> supp
edMembers, C) );
}
Kenji Hara
2013/6/8 Manu
> So from my dconf talk, I detailed a nasty hack to handle member function
> pointers in D.
> My approach is not portable, so I'd like to see an expression formalised
> in D, so this sort of interaction with C++ is possible, and al
On Monday, 10 June 2013 at 20:31:32 UTC, Simen Kjaeraas wrote:
or it should take a void* as its first
argument. void* means 'magic ahead', so it would be kinda ok.
This would encourage people to try something like
dg.funcptr(dg.ptr, ...), which is not correct ABI-wise.
David
On Mon, 10 Jun 2013 14:53:33 +0200, Jacob Carlborg wrote:
On 2013-06-10 14:36, Manu wrote:
funcptr pretends to be typed, but the type is just wrong. In your
example, the type is 'void function()', it should be 'void function(Foo
this)'.
"void function()" is part of the complete type. It bec
On Mon, 10 Jun 2013 12:45:12 -0400, Jacob Carlborg wrote:
On 2013-06-10 18:38, dennis luehring wrote:
maybe he just don't need one to handle the this ptr because he wants to
call several/hundrets of member-functions?
How does he call a pointer to a member function without the "this"
point
On 11 June 2013 02:43, Jacob Carlborg wrote:
> On 2013-06-10 18:34, Manu wrote:
>
>> On 11 June 2013 02:26, Jacob Carlborg mailto:d...@me.com>>
>>
>> wrote:
>>
>> On 2013-06-10 17:40, David Nadlinger wrote:
>>
>> Let me try to summarize it in code:
>>
>> ---
>> class A
On 2013-06-10 18:38, dennis luehring wrote:
maybe he just don't need one to handle the this ptr because he wants to
call several/hundrets of member-functions?
How does he call a pointer to a member function without the "this" pointer?
--
/Jacob Carlborg
Am 10.06.2013 18:28, schrieb Jacob Carlborg:
On 2013-06-10 17:36, Manu wrote:
My suggestion is: void function(T this) funcptr;
This is a function pointer (not a delegate), but using keyword 'this'
gives the critical detail to the compiler that it's a member function
pointer, and to use the appr
On 2013-06-10 18:34, Manu wrote:
On 11 June 2013 02:26, Jacob Carlborg mailto:d...@me.com>>
wrote:
On 2013-06-10 17:40, David Nadlinger wrote:
Let me try to summarize it in code:
---
class A { void foo(); }
auto memberFun = (&A.foo).funcptr;
auto a
On 11 June 2013 02:28, Jacob Carlborg wrote:
> On 2013-06-10 17:36, Manu wrote:
>
> My suggestion is: void function(T this) funcptr;
>> This is a function pointer (not a delegate), but using keyword 'this'
>> gives the critical detail to the compiler that it's a member function
>> pointer, and t
On 11 June 2013 02:26, Jacob Carlborg wrote:
> On 2013-06-10 17:40, David Nadlinger wrote:
>
> Let me try to summarize it in code:
>>
>> ---
>> class A { void foo(); }
>> auto memberFun = (&A.foo).funcptr;
>>
>> auto a = new A;
>> memberFun(a);
>> ---
>>
>
> Why is this better than a delegate?
On 2013-06-10 17:40, David Nadlinger wrote:
Let me try to summarize it in code:
---
class A { void foo(); }
auto memberFun = (&A.foo).funcptr;
auto a = new A;
memberFun(a);
---
Why is this better than a delegate?
--
/Jacob Carlborg
On 2013-06-10 17:36, Manu wrote:
My suggestion is: void function(T this) funcptr;
This is a function pointer (not a delegate), but using keyword 'this'
gives the critical detail to the compiler that it's a member function
pointer, and to use the appropriate calling convention when making calls
t
On Monday, 10 June 2013 at 14:43:50 UTC, Jacob Carlborg wrote:
On 2013-06-10 15:47, Manu wrote:
I'm really not asking for delegates (although they could
become more
typesafe given my suggestion), just a member function pointer.
And not
C++ style as you say, my suggestion is much simpler than t
On 11 June 2013 00:43, Jacob Carlborg wrote:
> On 2013-06-10 15:47, Manu wrote:
>
> I'm really not asking for delegates (although they could become more
>> typesafe given my suggestion), just a member function pointer. And not
>> C++ style as you say, my suggestion is much simpler than that, and
On 2013-06-10 15:47, Manu wrote:
I'm really not asking for delegates (although they could become more
typesafe given my suggestion), just a member function pointer. And not
C++ style as you say, my suggestion is much simpler than that, and would
fit nicely in D.
I give up, I don't understand w
On 2013-06-10 14:11:31 +, "David Nadlinger" said:
On Monday, 10 June 2013 at 14:04:29 UTC, Manu wrote:
On 10 June 2013 23:46, David Nadlinger
Another less intrusive option would be to just add extern(CppThisCall) and
extern(DThisCall) or something along the lines, which would be specifie
On 11 June 2013 00:28, Michel Fortin wrote:
> On 2013-06-10 14:11:31 +, "David Nadlinger"
> said:
>
> On Monday, 10 June 2013 at 14:04:29 UTC, Manu wrote:
>>
>>> On 10 June 2013 23:46, David Nadlinger
>>>
Another less intrusive option would be to just add extern(CppThisCall)
and
On Monday, 10 June 2013 at 14:04:29 UTC, Manu wrote:
On 10 June 2013 23:46, David Nadlinger
Another less intrusive option would be to just add
extern(CppThisCall) and
extern(DThisCall) or something along the lines, which would be
specified to
pass the first parameter as if it was a this point
On 10 June 2013 23:46, David Nadlinger wrote:
> On Friday, 7 June 2013 at 23:22:03 UTC, Manu wrote:
>
>> I think this makes good sense, because other than the choice of calling
>> convention, it really is just a 'function' in every other way.
>>
>
> Another less intrusive option would be to just
On 10 June 2013 23:49, David Nadlinger wrote:
> On Monday, 10 June 2013 at 13:45:37 UTC, Manu wrote:
>
>> What's the calling convention for
>> 'void function()'? cdecl?
>>
>
> Walter's very own calling convention. It is supposed to match cdecl
> everywhere but x86, but has the argument order reve
On Monday, 10 June 2013 at 13:45:37 UTC, Manu wrote:
What's the calling convention for
'void function()'? cdecl?
Walter's very own calling convention. It is supposed to match
cdecl everywhere but x86, but has the argument order reversed. On
x86, it's a custom one that's similar to stdcall in
On Friday, 7 June 2013 at 23:22:03 UTC, Manu wrote:
I think this makes good sense, because other than the choice of
calling
convention, it really is just a 'function' in every other way.
Another less intrusive option would be to just add
extern(CppThisCall) and extern(DThisCall) or something
roblem is that this "correct type" for the function pointer does
>> not exist currently. Calling a member function uses a different ABI, so
>> the type needs to know somehow its a pointer to a member function (and
>> that its first parameter is "this"), otherwise
ou can fabricate a compatible signature and it won't crash, but it's not
portable.
This is my whole point about the type-safety. If we create an expression to
describe a method pointer, then we can actually do it safely and portably.
So what I'm suggesting is a syntax to express a
On Monday, 10 June 2013 at 12:53:34 UTC, Jacob Carlborg wrote:
On 2013-06-10 14:36, Manu wrote:
funcptr pretends to be typed, but the type is just wrong. In
your
example, the type is 'void function()', it should be 'void
function(Foo
this)'.
"void function()" is part of the complete type. It
08-Jun-2013 03:21, Manu пишет:
So from my dconf talk, I detailed a nasty hack to handle member function
pointers in D.
My approach is not portable, so I'd like to see an expression formalised
in D, so this sort of interaction with C++ is possible, and also it may
be useful in D code dir
(and
that its first parameter is "this"), otherwise the generated code at the
call site will be all wrong.
Then he's asking for (more) type safe delegates and support for C++
member function pointers.
--
/Jacob Carlborg
tax to express a member function pointer,
and then it could be properly typed.
I don't think there's anything wrong with supporting C++ member function
pointers but I don't think we need to add new syntax for it.
--
/Jacob Carlborg
On 10 June 2013 21:35, Jacob Carlborg wrote:
> On 2013-06-10 11:45, Manu wrote:
>
> A function pointer is a pointer. A delegate is a pointer to a function
>> and a context pointer, ie, 2 pointers.
>> A pointer to a method is just a pointer to a function, but it's a
>> special function which rece
o yet... but that doesn't mean it might not be useful.
It would probably be used in D for tight binding with other systems.
AngelScript binds to native code with member function pointers... just
off the top of my head.
Actually I don't see why you can't use a delegate for this. The only
On 2013-06-10 11:45, Manu wrote:
A function pointer is a pointer. A delegate is a pointer to a function
and a context pointer, ie, 2 pointers.
A pointer to a method is just a pointer to a function, but it's a
special function which receives a 'this' argument with a special calling
convention.
It
g
convention, otherwise it's just a delegate like usual.
I haven't needed to yet... but that doesn't mean it might not be useful.
>> It would probably be used in D for tight binding with other systems.
>> AngelScript binds to native code with member function pointers... ju
doesn't mean it might not be useful.
It would probably be used in D for tight binding with other systems.
AngelScript binds to native code with member function pointers... just
off the top of my head.
Actually I don't see why you can't use a delegate for this. The only
differen
On 10 June 2013 16:50, Jacob Carlborg wrote:
> On 2013-06-08 01:21, Manu wrote:
>
>> So from my dconf talk, I detailed a nasty hack to handle member function
>> pointers in D.
>> My approach is not portable, so I'd like to see an expression formalised
>> in D,
On 2013-06-08 01:21, Manu wrote:
So from my dconf talk, I detailed a nasty hack to handle member function
pointers in D.
My approach is not portable, so I'd like to see an expression formalised
in D, so this sort of interaction with C++ is possible, and also it may
be useful in D code dir
On 8 June 2013 12:29, Michel Fortin wrote:
> On 2013-06-07 23:57:40 +, Manu said:
>
> Precisely. The concept is already embedded inside of delegate, but
>> delegate
>> is framed like a piece of magic, rather than a well defined compound of
>> more primitive pieces.
>>
>
> Delegates are not
On 2013-06-07 23:57:40 +, Manu said:
Precisely. The concept is already embedded inside of delegate, but delegate
is framed like a piece of magic, rather than a well defined compound of
more primitive pieces.
Delegates are not parametrized on the type of "this", which makes them
easier to
On Saturday, 8 June 2013 at 01:11:46 UTC, Manu wrote:
I initially started with something like this. But look how much
code it is!
Yeah...
You've basically wrapped up a delegate, and made something that
emulates a delegate
(I'm not sure why?).
I just wanted to add type safety to a delegate;
On 8 June 2013 10:24, Adam D. Ruppe wrote:
> On Friday, 7 June 2013 at 23:54:55 UTC, Manu wrote:
>
>> The properties are already there...
>> but they're not properly typed.
>>
>
> I just don't think they can be unless we change the visible type which
> isn't always what we want but, check thi
On Friday, 7 June 2013 at 23:54:55 UTC, Manu wrote:
The properties are already there...
but they're not properly typed.
I just don't think they can be unless we change the visible type
which isn't always what we want but, check this out:
// this new type keeps track of the exact type of
c/syntax/#selector-literals>
>
> Not only I think member function pointers are doable, but I think they're
> solely missing. There have been situations where I'd have used them but
> instead had to hack my way using a delegate. That was to build a bridge for
> Objective-C (b
On 8 June 2013 09:42, Adam D. Ruppe wrote:
> On Friday, 7 June 2013 at 23:22:03 UTC, Manu wrote:
>
>> Currently, to get the instance or function pointers from a delegate, you
>> need to do something like:
>>
>
> delegates have two members, ptr and funcptr:
> http://dlang.org/function.html
>
> As
On 2013-06-07 23:21:53 +, Manu said:
Thoughts?
Reminds me of something similar I implemented a while ago:
http://michelf.ca/projects/d-objc/syntax/#selector-literals
Not only I think member function pointers are doable, but I think
they're solely missing. There have been situa
On Friday, 7 June 2013 at 23:22:03 UTC, Manu wrote:
Currently, to get the instance or function pointers from a
delegate, you need to do something like:
delegates have two members, ptr and funcptr:
http://dlang.org/function.html
As a fun fact, if you modify druntime's allocator to be malloc(),
So from my dconf talk, I detailed a nasty hack to handle member function
pointers in D.
My approach is not portable, so I'd like to see an expression formalised in
D, so this sort of interaction with C++ is possible, and also it may be
useful in D code directly.
I'm thinking something
http://www.reddit.com/r/programming/comments/9q52z/member_function_pointers_and_the_fastest_possible/
68 matches
Mail list logo
