meta: dealing with language differences between C++ and nim

[haxscramper]

• nim does not have type-level immutability annotations, and instead relies on mutability of the symbols. You can't have immutable field, only immutable variable.
  • CppConst*[T] timotheecour/Nim#489
  • distinguish ccstring (const char*) from cmstring (char*) timotheecour/Nim#524
• Reusing nim method for wrapping C++ methods #1 and Overriding C++ clases on the nim side (current best implementation idea) #2 very hard to properly interface with Cxx classes. Numerous workarounds can be implemented, but all of them have limitations
  • https://forum.nim-lang.org/t/4229
  • https://forum.nim-lang.org/t/4220
• Inner typedef handling #3 full explanation in linked issue. It might be possible to provide some form of simplified workaround that shifts responsibility to the end user. It might be the only way of reliably solving this.
• C++ move semantics, copying, destructors, memory management #13 nim and cxx have completely different understanding of move semantics.
• memory management using GC types and ref - thankfully cxx has placement new, so at least I'm able to explain nim gc how to manage cxx objects.
• Wrapping macro and conditional compilation semantics #21 - of course, bane of all attempts for interfacing with C languages - it's "meta" "programming" capabilities.

Additional related links

• wrapper-free interop with C/C++ nim-lang/Nim#8327
• C++ interop timotheecour/Nim#439

[haxscramper]

Const is a huge PITA - I dynlib deals with the inconsistencies by generating code like (it just ignores const-ness of the argument)

typedef N_CDECL_PTR(NCSTRING, tyProc__cTCodr69cPNr9chtH7apXJYg) (NCSTRING s);
Dl_4294968796_ = (tyProc__cTCodr69cPNr9chtH7apXJYg) nimGetProcAddr(TM__xDZurH9b9cD5SoY3HyXHwqcw_2, "wave_unescapeIncludeToken");

and then calling it, but if I try to do a simple importc it seems that I either have to header: the procedure import, or make sure the header is never imported, otherwise I get a conflicting types error.

wave_c_api.h defines types, I import them using header:, but at the same time for regular procedures it is more problematic.

[haxscramper]

[...]/@mnim_cxx_const_main.nim.c:63:15: error: conflicting types for ‘get_cstring_link’; have ‘void(char *)’
   63 | N_CDECL(void, get_cstring_link)(NCSTRING str);
      |               ^~~~~~~~~~~~~~~~
/home/test/.choosenim/toolchains/nim-1.6.0/lib/nimbase.h:201:44: note: in definition of macro ‘N_CDECL’
  201 | #    define N_CDECL(rettype, name) rettype name
      |                                            ^~~~
In file included from [...]: note: previous declaration of ‘get_cstring_link’ with type ‘void(const char *)’
    6 | void get_cstring_link(const char* cstring);
      |      ^~~~~~~~~~~~~~~~

nim_cxx_const_main.nim

const
  h = "lib.h"
  l = "liblib.so"

type
  str {.importc: "struct str", header: h.} = object
    field: cint

echo str()

proc get_cstring_dl(str: cstring) {.dynlib: l, importc: "get_cstring_dl".}

get_cstring_dl(nil)

proc get_cstring_link(str: cstring) {.cdecl, importc: "get_cstring_link".}

get_cstring_link(nil)

xmake.lua

target("lib")
    set_kind("shared")
    add_files("lib.c")
    set_targetdir(os.scriptdir())

target("main")
    set_kind("binary")
    add_deps("lib")
    add_files("nim_cxx_const_main.nim")
    add_links("lib")
    set_targetdir(os.scriptdir())

lib.c

void get_cstring(const char* cstring) {}
void get_cstring_link(const char* cstring) {}

lib.h

struct str {
    int field;
};

void get_cstring_dl(const char* cstring);
void get_cstring_link(const char* cstring);

Reproduce with xmake

---

nodecl fixes that for C backend, but in C++ I get ‘get_cstring_link’ was not declared in this scope int T4_ = get_cstring_link(((NCSTRING) NIM_NIL));

[haxscramper]

I think this could've been trivially solved if Const[T] {.importcpp: "const '*0".} worked correctly, but right now it

1. Does not work (generates const '*0 T1_;)
2. Implicitly promotes file to the C++ backend, failing compilation

Can this be fixed by making importcpp: work the same way in procs and type imports?

[haxscramper]

I can wrap each type twice - as a regular object and as a const. This approach is of course insane, since I can also have ptr T, ptr ptr T, ref T and so on, but this way nim would generate correct procedure prototypes.