fficxx
fficxx copied to clipboard
wavewave
Haskell-C++ Foreign Function Interface Generator
Before moving towards a full IDL approach, it is good to eliminate extra-compilation step for generation code. We can achieve this by run-time compilation using GHC API after making fficxx...
`int*`, `char*`, `int&` are treated in an _ad hoc_ way. We should unify this with already-existing generic pointer/ref infra.
Now that we support `std::function`, it is desirable to support casting function parameters from Haskell FFI types to C++ types. Note that Haskell-C++ type/class correspondence is not 1-1 or 1-N,...
Like `*.Interface` modules, `*.Template` modules used in other Template or Interface should be defined as hs-boot. ### Context We split each class into separate Haskell module, but each class may...
C++ template support has been implemented. We need some extensive documentation on how to use it (and also some explanation about how it works). Old comment by @dfordivam. I see...
Destructor introduces a virtual method `delete`. But since every deletable class has the method, we have a big name conflict. We had better revert old IDeletable superclass.
cppclass and cppclasscopy are quite confusing. We had better move towards Bare | Pointer | Ref | RefRef modifier semantics some time soon.
Representation of C/C++ types in fficxx is quite ad hoc. As the library gets more mature, we need to reorganize this to a better representation for more readable code.
We use opaque struct for ordinary class and `void*` for template class. After all, opaque struct is `void*` with additional type safety in C. Since Haskell manages all the type...