[m-users.] foreign_type confusion on how to do it across modules...

[emacstheviking]

Zoltan,
for the record, from the SDL_Rect.h header file...










*typedef struct SDL_Point{    int x;    int y;} SDL_Point;typedef struct
SDL_Rect{    int x, y;    int w, h;} SDL_Rect;*

so they are not pointers but actual structures. If I wrote a funtion that
allocated memory then I would have to de-allocate it as well ...a level of
complexity I wouldn't have hoped not to have been presented with for just
shuffling rectangles around. I had hoped that some kind of local stack
based allocation would have taken place (no idea how the compiler works,
can you tell?) e/g/ like RAII in C++ sort of thing.

However, I think I have enough information from you and Julien and Julian
to be able to move forward in a reasonable manner.
Thank you all once again,
Sean.


On Sun, 14 Jul 2019 at 00:24, Zoltan Somogyi <zoltan.somogyi at runbox.com>
wrote:

>
>
> On Sat, 13 Jul 2019 23:53:28 +0100, emacstheviking <objitsu at gmail.com>
> wrote:
> > *    % SDL_Rect:- type sdl_rect.:- pragma foreign_type("C", sdl_rect,
> > "SDL_Rect", [can_pass_as_mercury_type]).*
>
> If you have that definition in your code, but not ...
>
> > *:- type sdl_rect ---> sdl_rect(x::int, y::int, w::int, h::int).*
>
> ... this definition, then only C code knows the structure of this type, and
> therefore only C code can create values of this type.
>
> > *  sdl_renderfillrect(Rnd, sdl_rect(0, 50, 200, 100), !IO),*
>
> This means that if you want to be able to write code like that, you will
> need to define a Mercury function sdl_rect/4, whose implementation
> will be a foreign_proc that allocates memory for a structure and fills in
> its fields
> before returning a pointer to it. (I presume that SLD_Rect is a typedef
> for a
> pointer to a structure type.)
>
> In C, the allocation should be done with the MR_GC_NEW macro,
> which is defined in runtime/mercury_memory.h, or its MR_GC_NEW_ATTRIB
> variant, which help with memory profiling.
>
> Julien, Peter: I see that the reference manual is silent on how foreign
> code should
> allocate memory whose address is passed to Mercury code. Since you have
> more
> experience with interfacing to foreign language code than I do, could one
> of you
> please take a crack at adding a paragraph about this to the sections
> dealing
> with the interfaces to C, C#, Java and Erlang?
>
> Zoltan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20190714/cafb3894/attachment.html>