C binding does not seem to be usable.

[briansturgill]

It's true for many of the calls in the C binding, but here's the one I hit first:

ManifoldCrossSection *manifold_cross_section_circle(void *mem, float radius,
                                                    int circular_segments) {
  auto cs = CrossSection::Circle(radius, circular_segments);
  return to_c(new (mem) CrossSection(cs));
}

How is a caller (outside of C++) supposed to know what size "mem" should be?

The call seems to be trying to copy the CrossSection into caller provided memory?
Why is the copy necessary?

[geoffder]

See the manifoldc tests for usage examples. *mem should be the size of a CrossSection in this case, which you can get with manifold_cross_section_size(). The reason for this pattern is that the C bindings are designed for use via FFI from garbage collected languages (e.g. OCaml, which is what I have used them for, but others have already used them for Java going by a previous PR), which might prefer to allocate memory themselves such that it can be tracked/finalized properly.

The Manifold library returns fresh Manifold values from all of its methods, but we want them to be placed in the user provided memory hence the copy. Note however that the copy should be elided by the compiler since there isn't really any funny business between the creation of the values and the construction with new (mem).

For an example of using manifold_cross_section_circle, here is an excerpt from my OCaml bindings. Note that this is already after using the Ctypes library to auto-generate stubs for the basic FFI bindings to manifoldc.

type t = C.Types.CrossSection.t Ctypes_static.ptr

let size = C.Funcs.cross_section_size () |> size_to_int
let destruct t = C.Funcs.destruct_cross_section t

let alloc () =
  let finalise = Mem.finaliser C.Types.CrossSection.t destruct in
  let buf = Mem.allocate_buf ~finalise size in
  ( buf
  , Ctypes.coerce Ctypes_static.(ptr void) Ctypes_static.(ptr C.Types.CrossSection.t) buf
  )

let circle ?(fn = 0) rad =
  let buf, t = alloc () in
  let _ = C.Funcs.cross_section_circle buf rad fn in
  t

[briansturgill]

Thanks for the assistance!
I've got it working now.

[NickUfer]

Just stumbled upon something similar while building rust bindings for this project. I'm no professional when it comes to C/C++ or developing bindings for these in rust and I wonder how this (de)allocation really is supposed to work.
There are functions like manifold_manifold_size() which return the sizes of these structs, but the structs include e.g. vectors which are not fixed size and are somewhere else in memory, just (AFAIK) not in the space allocated by the bindings using program, as we can't know the size yet.

From my understanding with the current pattern we got all the stuff where we know the size at compile time in memory provided by the user, but the vectors in the memory allocated by Manifold, and for releasing the memory we also call a function in Manifold, where I expect we call the release function on the user side, as this is the one which allocated the memory in the first place.

So far I tried some things to rectify this a bit, but everything except this weird pattern leaks memory. Only the current version, where memory is allocated by the user side and deleted on the Manifold side does not leak memory... and I can't understand why that is.

One thing I tried is adding an allocation function to allocate the memory in Manifold too, as it is already the case for deletion:

ManifoldManifold* manifold_alloc_manifold() { return to_c(new Manifold); }

But calling this allocation function and later the manifold_delete_manifold() leaks memory too.

Any ideas why that might be?

[geoffder]

When we allocate memory for these complex structures (e.g. vectors and Manifold) in C, we aren't actually allocating the memory that the arrays are stored in (as you note, we can't know how much memory they need). Instead we are allocating memory for pointers that point to the memory where those things are stored (which is managed on the C++ side via shared ptrs etc). That's why they are always the same.

[NickUfer]

Thanks for the reply 👍🏼 Thats what I suspected is going on.

Btw, regarding the other problem I had with the manifold_alloc_manifold() func I mentioned: Just fixed the memory leak after I found out that new Manifold does not allocate exactly sizeof(Manifold), but for whatever reason a little bit more than that.

This is the correct version:

ManifoldManifold* manifold_alloc_manifold() {
  return to_c((Manifold*)malloc(manifold_manifold_size()));
}