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?

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

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

"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?

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

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

"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*

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