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

[Zoltan Somogyi]

On Sun, 14 Jul 2019 10:13:12 +0100, emacstheviking <objitsu at gmail.com> wrote:

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

Then the size of an SDL_Rect is bigger than a size of an MR_Word, and therefore
the can_pass_as_mercury_type attribute you gave in the foreign type definition
was a lie. If you lie to the compiler, the results are never pretty. In this case, you
would only get a core dump if you are lucky; if you are unli

Please read reference manual section 14.4 on the attributes on foreign types,
particularly the warnings on their use.

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

The whole point of the MR_GC_NEW macro is to AVOID the need for
explicit deallocation. That macro invokes the memory allocator of the Boehm-
Demers-Weiser garbage collector, The C code generated by the Mercury
compiler uses the same system. Memory blocks allocated by this allocator
will be garbage collected automatically.

> I had hoped that some kind of local stack
> based allocation would have taken place (no idea how the compiler works,
> can you tell?)

How can the Mercury compiler allocate memory for an SDL_Rect, either on
a stack or elsewhere, when it does not know how many bytes an SDL_Rect\
needs?

> e/g/ like RAII in C++ sort of thing.

The C++ compiler is working with structures over whose layout, and therefore
size, it has full control over.

Zoltan.