Mirror of forum.nim-lang.org

96 :: Exporting types from nimrod to C/C++/ObjC?

• gradha (orginal) [2012-10-22T20:18:27+02:00] view original

  I'm going through the docs and source finding examples of external C/C++/ObjC code and structures being made available to Nimrod thanks to the importc pragma. The reverse direction can be accomplished through the use of the exportc pragma. This works fine for procs but I haven't seen it used at all for complex types, like structures. I have a nimrod object which I want to make available to C:

  type
    TWeight {.exportc.} = object of TObject
      id*: int
      date*: TTime
      weight*: float
    PWeight = ref TWeight
  Run

  This generates an unpromising typedef struct TWeight TWeight; in the respective header file, with no access to the internals. The implementation uses the following code:

  struct TWeight {
    TNimObject Sup;
  NI id;
  time_t date;
  NF weight;
  };
  Run

  But it is not available in the header file, and I presume bad stuff might happen if I try to modify the structure under Nimrod's feet. Is there any provision to make structures available to the C-like side? AFAICS now the sane option would be to generate C/C++/ObjC code duplicating the structures used in nimrod and write simple "copy this to there" methods in nimrod which filled the C native structures. With the side effect that these would be copies, so no changes on the C side would propagate back.

  Ok, that's not very sane either. Maybe the idea is that I should write getter/setters in nimrod which get exported to the C version? I can see that working, with the C version treating these objects as opaque and always invoking the nimrod generated code to deal with them. Hmmm... not that bad. I can see that getting in the performance of simple types, but at least it seems viable.

  Is there any pragma or way to autogenerate getter/setters for the exported C code?

  Also, how does the memory pointer play with the garbage collection? Can the gc move the structure in nimrod space to say compact the memory blocks it manages invalidating the plain C pointer? What about the lifetime of nimrod objects vs C space?

---

• Araq (orginal) [2012-10-22T23:16:24+02:00] view original

  Maybe the idea is that I should write getter/setters in nimrod which get exported to the C version?

  You think too much... ;-) It's an oversight of mine that the header does not contain all the fields... However you can produce Nimrod setter and getter boilerplate with a macro and 'exportc' those.

  Also, how does the memory pointer play with the garbage collection?

  This is implementation dependent but the current implementation will stay around for a while: Nimrod's GC does not move objects and scans the C stack conservatively. If the C code stores a Nimrod ref/string/seq anywhere else 'incRef' and 'decRef' must be used.

---