www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Pointer to C++ member possible?

reply Raynor <memphis007fr yahoo.fr> writes:
I want to use the QT4 library for the GUI and D the D for the core.
I think its more simple to make the controllers in C++.
I manage to call D methods from C++ and vice versa with C++ 
interoperability feature from D 2.0.
But i need a signal system so the core can emit signals to the controllers.
Everything is objet so i need pointer to C++ member for the signals.

Is there any way to do that?
Mar 09 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Raynor" <memphis007fr yahoo.fr> wrote in message 
news:fr1ach$1qmd$1 digitalmars.com...

I want to use the QT4 library for the GUI and D the D for the core.
 I think its more simple to make the controllers in C++.
 I manage to call D methods from C++ and vice versa with C++ 
 interoperability feature from D 2.0.
 But i need a signal system so the core can emit signals to the 
 controllers.
 Everything is objet so i need pointer to C++ member for the signals.

 Is there any way to do that?


There is no standardized ABI for C++ pointers-to-members, making it terribly 
difficult to interface with them.  You basically have to find out how the 
particular C++ compiler you're using implements pointers-to-members and 
implement it, non-portably, using D.
Mar 09 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jarrett Billingsley wrote:

 "Raynor" <memphis007fr yahoo.fr> wrote in message 
 news:fr1ach$1qmd$1 digitalmars.com...

 I want to use the QT4 library for the GUI and D the D for the core.
 I think its more simple to make the controllers in C++.
 I manage to call D methods from C++ and vice versa with C++ 
 interoperability feature from D 2.0.
 But i need a signal system so the core can emit signals to the 
 controllers.
 Everything is objet so i need pointer to C++ member for the signals.

 Is there any way to do that?


 
 There is no standardized ABI for C++ pointers-to-members, making it terribly 
 difficult to interface with them.  You basically have to find out how the 
 particular C++ compiler you're using implements pointers-to-members and 
 implement it, non-portably, using D. 


There's no standardized ABI for name mangling either, but calling a C++ 
mangled name is what D's extern(C++) lets you do.  From what I 
understand it just picks a particular ABI, e.g. DMD uses DMC's ABI. 
If/when GDC supports it, it will use the g++ ABI.

So no standard ABI is not really a reason for not supporting it. 
Handling the non-standard ABI is supposed to be the job of extern(C++).

But seems like lack of a similar concept in D is a problem.  The topic 
of C++-like pointer-to-member has come up before.  I think there is some 
sort of hack to do a D version of it by setting the delegate's .ptr 
property?  Casting to void* and setting it seems to work:

class Foo
{
     private int value;
     this(int v) { value = v; }
     int member() { return value; }
}
void main()
{
     auto x = new Foo(1);
     auto y = new Foo(2);

     auto dg = &x.member;
     writefln("DG -> ", dg());
     dg.ptr = cast(void*)y;
     writefln("DG -> ", dg());
}

But you may be on thin ice with that, since as far as I can see this is 
all the spec has to say about the .ptr on delegates:
   "The .ptr property of a delegate will return the frame pointer value 
as a void*."

So doesn't say anything about /setting/ it.

--bb
Mar 09 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:fr1hre$2ha9$1 digitalmars.com...


 There's no standardized ABI for name mangling either, but calling a C++ 
 mangled name is what D's extern(C++) lets you do.  From what I understand 
 it just picks a particular ABI, e.g. DMD uses DMC's ABI. If/when GDC 
 supports it, it will use the g++ ABI.

 So no standard ABI is not really a reason for not supporting it. Handling 
 the non-standard ABI is supposed to be the job of extern(C++).


Good point.


 But seems like lack of a similar concept in D is a problem.  The topic of 
 C++-like pointer-to-member has come up before.  I think there is some sort 
 of hack to do a D version of it by setting the delegate's .ptr property? 
 Casting to void* and setting it seems to work:


Works for pointers-to-member-functions (that is, if the given C++ ABI uses 
the same ABI as a delegate), but what about pointers-to-member-data?
Mar 09 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jarrett Billingsley wrote:


 But seems like lack of a similar concept in D is a problem.  The topic of 
 C++-like pointer-to-member has come up before.  I think there is some sort 
 of hack to do a D version of it by setting the delegate's .ptr property? 
 Casting to void* and setting it seems to work:


 
 Works for pointers-to-member-functions (that is, if the given C++ ABI uses 
 the same ABI as a delegate), but what about pointers-to-member-data? 


Is there such a thing in C++?  AFAIK pointer-to-member-data is just the 
same thing as "pointer-to-data" in both C++ and D.  Anyway if c++ does 
have it, I think you could fake it with .offsetof and casts.
( http://www.digitalmars.com/d/1.0/class.html )

However, .offsetof seems broken at the moment.  This example for the 
docs doesn't compile for me:

class Foo
{
     int x;
}
...
void test(Foo foo)
{
     size_t o;

     o = Foo.x.offsetof;   // yields 8
}

With dmd 1.028 I get:

ptrmemfun.d(29): Error: 'this' is only allowed in non-static member 
functions, not test
ptrmemfun.d(29): Error: this for value needs to be type Foo not type int


--bb
Mar 09 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Bill Baxter wrote:

 
 However, .offsetof seems broken at the moment.  This example for the 
 docs doesn't compile for me:
 
 class Foo
 {
     int x;
 }
 ...
 void test(Foo foo)
 {
     size_t o;
 
     o = Foo.x.offsetof;   // yields 8
 }
 
 With dmd 1.028 I get:
 
 ptrmemfun.d(29): Error: 'this' is only allowed in non-static member 
 functions, not test
 ptrmemfun.d(29): Error: this for value needs to be type Foo not type int


Looks like I'm not the first to notice:
http://d.puremagic.com/issues/show_bug.cgi?id=515

--bb
Mar 09 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:fr1jhb$2lv0$2 digitalmars.com...

 Looks like I'm not the first to notice:
 http://d.puremagic.com/issues/show_bug.cgi?id=515

 --bb


Sad that it's been open for 16 months with no response of any kind.  *sigh*
Mar 09 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Jarrett Billingsley wrote:

 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
 news:fr1jhb$2lv0$2 digitalmars.com...

 Looks like I'm not the first to notice:
 http://d.puremagic.com/issues/show_bug.cgi?id=515

 --bb


 
 Sad that it's been open for 16 months with no response of any kind.  *sigh* 


Not that sad, considering I think it went straight from being a feature 
that didn't exist at all to one that merely doesn't work.  So it didn't 
break anyone's code.  Just... there wasn't much point putting it in the 
spec in the first place if it doesn't actually work.

--bb
Mar 09 2008