Mik*_*kov 23
它们都具有相同的功能:使编写FFI绑定更容易.如果你选择使用c2hs,你不需要知道hsc2hs; 他们是独立的.C2hs更强大,但也更复杂:Edward Z. Yang在他的c2hs教程中用一个漂亮的图表说明了这一点:
我什么时候应该使用c2hs？有许多Haskell预处理器; 你应该使用哪一个？表征上述层次结构的一种简短(有些不准确)的方法是你走的越远,你必须编写的样板越少,你需要阅读的文档越多; 因此,我听说过hsc2hs应该用于小型FFI项目,而c2hs更适合大型项目.
c2hs支持hsc2hs不支持的事情:
- 根据C头文件的内容自动生成外部导入
- 半自动编组与函数调用,和
- 将指针类型和层次结构转换为Haskell类型.
- @Dan我不相信这是真的.C++变得更加复杂,请参阅模板等. (2认同)
- @Dan:事实并非如此.C不支持函数重载,模板,异常,方法......尽管在C++核心上提供C-ish接口总是可行的. (2认同)
scl*_*clv 10
米哈伊尔的答案很好,但还有另一面.还有一些hsc2hs提供的东西,c2hs没有,并且可能有必要同时使用它们.
值得注意的是,hsc2hs通过生成运行生成Haskell代码的C可执行文件来运行,而c2hs直接解析头文件.因此,hsc2hs允许你访问#defines等.所以虽然我发现c2hs更好地生成绑定和包装器绑定以及"深入"窥视和戳到复杂的C结构,但它不利于访问常量和枚举,并且它只能温和地自动化可存储实例的样板.我发现hsc2hs也是必需的,与bindings-dsl包[1]结合使用,特别是在我的情况下对于预定义的常量.在一个实例中,我有一个用于大量常量的hsc文件,以及一个用于包装使用这些常量的函数的chs文件.
[1] http://hackage.haskell.org/package/bindings-DSL
- 这仍然是事实,但C2HS的情况在过去几年中有所改善.例如,`enum`支持现在相当好一些,你可以访问`#simic`的值,还有一些编组支持,有更好的外部指针支持,等等.(当我必须包装C库时,我仍然倾向于编写C2HS和普通FFI代码的混合,因为有很多事情是C2HS无法做到的.) (3认同)