Hi, I'm working with the X11 library available from https://github.com/D-Programming-Deimos/libX11
If I try to call XSynchronize(display, True) the compilation fails with "Error: function deimos.X11.Xlib.XSynchronize (_XDisplay*) is not callable using argument types (_XDisplay*, int)"

I am sure the arguments are correct (see http://goo.gl/8Hzn8s for example) so I think there is a conversion problem between the C and D definition of the function:

--- Xlib.h
extern int (*XSynchronize(
    Display*		/* display */,
    Bool		/* onoff */
))(
    Display*		/* display */
);

--- Xlib.d
extern int function(
    Display*            /* display */,
    Bool                /* onoff */
)XSynchronize(
    Display*            /* display */
);


Also I can't understand why the C version is not "extern int XSynchronize(Display*,
    Bool);" which would be the simplest definition.

andrea9940:

> extern int function(
>     Display*            /* display */,
>     Bool                /* onoff */
> )XSynchronize(
>     Display*            /* display */
> );

Try extern(C)?

Bye,
bearophile

On Tuesday, 6 August 2013 at 08:21:26 UTC, bearophile wrote:
> Try extern(C)?

It's not a linkage error, it's a syntax one

On 08/06/2013 01:01 AM, andrea9940 wrote:

> Hi, I'm working with the X11 library available from
> https://github.com/D-Programming-Deimos/libX11
> If I try to call XSynchronize(display, True) the compilation fails with
> "Error: function deimos.X11.Xlib.XSynchronize (_XDisplay*) is not
> callable using argument types (_XDisplay*, int)"
>
> I am sure the arguments are correct (see http://goo.gl/8Hzn8s for
> example) so I think there is a conversion problem between the C and D
> definition of the function:
>
> --- Xlib.h
> extern int (*XSynchronize(
>      Display*        /* display */,
>      Bool        /* onoff */
> ))(
>      Display*        /* display */
> );

I have written the following stubs for C:

typedef void Display;
typedef int Bool;

extern int (*XSynchronize(
    Display*        /* display */,
    Bool        /* onoff */
))(
    Display*        /* display */
);

typedef int(*PreviousAfterFunction)(Display*);

int previous_after_foo(Display* display)
{
    return 0;
}

PreviousAfterFunction XSynchronize(Display* display, Bool onoff)
{
    return &previous_after_foo;
}

int main()
{
    int (*paf)(Display*) = XSynchronize(0, 1);
    paf(0);
}

And then I have written the direct translation in D, which works as well:

struct Display
{}

alias PreviousAfterFunction = int function(Display*);

int previousAfterFoo(Display *)
{
    return 0;
}

PreviousAfterFunction XSynchronize(Display*, bool)
{
    return &previousAfterFoo;
}

void main()
{
    PreviousAfterFunction paf = XSynchronize(null, 1);
    paf(null);
}

> --- Xlib.d
> extern int function(
>      Display*            /* display */,
>      Bool                /* onoff */
> )XSynchronize(
>      Display*            /* display */
> );

It looks like Xlib.d got it backwards: XSynchronize takes two parameters and returns a function pointer that takes a single parameter. It should be the following:

int function(Display*) XSynchronize(Display*, bool);

> Also I can't understand why the C version is not "extern int
> XSynchronize(Display*,
>      Bool);" which would be the simplest definition.

That's different. That would be a function taking two parameters and returning int. However, XSynchronize takes two parameters and return a function pointer (that takes one parameter and returns an int).

Ali

> struct Display
> {}

D supports opaque structs/pointers

struct Display;

Now Display has to be used as pointer only or the compiler complains e.g. about

Display display;

@Ali Çehreli
Thank you for the explanation. I'll send a pull request to fix Xlib.d

On 08/06/2013 03:22 AM, David wrote:>> struct Display
>> {}
>
> D supports opaque structs/pointers
>
> struct Display;
>
> Now Display has to be used as pointer only or the compiler complains
> e.g. about
>
> Display display;

Yes and I am sure that is how Xlib.d has it.

However, remembering a limitation that we have discovered a couple of weeks ago, I intentionally did not make it opaque, in case somebody would try toString() on it:

  http://forum.dlang.org/post/ksc2ln$f1i$1@digitalmars.com

I have been to lazy to bring this topic up on the main newsgroup before opening an enhancement request.

Ali

On 08/06/2013 08:46 AM, Ali Çehreli wrote:

> On 08/06/2013 03:22 AM, David wrote:>> struct Display
>  >> {}
>  >
>  > D supports opaque structs/pointers
>  >
>  > struct Display;
>  >
>  > Now Display has to be used as pointer only or the compiler complains
>  > e.g. about
>  >
>  > Display display;
>
> Yes and I am sure that is how Xlib.d has it.
>
> However, remembering a limitation that we have discovered a couple of
> weeks ago, I intentionally did not make it opaque, in case somebody
> would try toString() on it:

I am confused and being confusing... I think nobody should apply toString() on an opaque type as it is supposed to dereference the actual object.

>    http://forum.dlang.org/post/ksc2ln$f1i$1@digitalmars.com

I will continue on that thread.

Ali