Calling C++ from Hover

Hover transpiles to C++, which makes calling external C or C++ cheap: there's no marshalling layer, just a header injected into the generated source and a signature the semantic analyser can type-check against. Two constructs do it — importc and extern func.

The importc directive

Unlike import, which evaluates other Hover files, importc is a direct pass-through to the C++ code generator. It does not parse the target file. It instructs the compiler to inject a C++ #include at the top of the generated simulation code:

That's what makes the external definitions available to the linker when the final C++ is compiled.

extern func declarations

To call an external function, Hover's semantic analyser needs its signature — parameters and return type — so it can enforce type safety at compile time. extern func is a forward declaration: an interface with no body.

Putting it together

Once the header is included and the signature registered, the external function can be called anywhere a normal function can — inside a digital or analog module.

Hover's type system stops at primitive numerics, so a C++ struct can't appear in an extern func signature. See Structs & complex types for the two patterns that get around it.

Building

When a simulation depends on external FFI files, make sure the corresponding .c or .cpp sources are part of your build so they're compiled and linked with the generated output. See Build targets for the compile line.

Because that link step pulls in native source alongside your circuit, treat a .hvr file the way you'd treat a build script from an untrusted source: compiling it can compile and run arbitrary native code.

For the other direction of interop — driving a compiled Hover simulation from a host program — see Hovercraft.