…they opted for an animal that was not well known on the web at the time. It was the red panda. Unfortunately, people thought that the animal on the Mozilla Firefox logo was a fox. This “firefox” is actually a red panda which is a protected species in Asia. A mistake when translating red panda from Chinese to English is how we got firefox.
姑且不说你们搞清楚我讽刺的点在哪没有,请问你们可以拿现在的剑去圆去年前年吹的 b 吗?作为一个程序员,始终对华为终端在软件上的吹逼行为十分讨厌。而且花粉们似乎已经接受了这样的现实,还觉得“大嘴吹过的皮全都实现了”。这种空手套沸腾的行为,不是华为还真不敢干。论营销,你以为华为在负一层,其实他在第五层。这些人搞得我心态爆炸真的烦,我就想看看鸿蒙 2.0 到底是个什么东西。
说到 FFI,FFI to C 大概算得上是事实标准了。Rust 也提供了 to C 的 FFI,但如果我们想把 Rust 结构包装成对象提供给其他语言使用,事情就没那么简单了。
一种方法是完全依赖于源语言的对象模型,典型的例子是 SWIG。SWIG
是一个 C/C++ 的 Wrapper Generator,通过 parse C/C++
头文件、结合不同的后端,可以输出不同语言的绑定。它的思路是比较简单的:C++ 中的成员方法全部包装为 extern C 的普通函数,接收 C++
对象的指针;目标语言这边的对象只携带一个 C/C++ 对象的指针就可以了。我之前用 SWIG 做过一个 Wrapper,wrap 了
wxWidgets(一个 C++ 库)给 golang 用,比较头疼的是:
内存管理。一般的 C++
类都不会自带引用计数,这时候怎么处理裸指针就很头疼,每个函数的返回值和参数都需要(人工)分析出对象的所有权是否转移,以便决定需不需要在 Go
这一侧调用 delete。同时,如果所有权在 C++ 一侧,如何判断对象是否已经释放,仍然比较难办。如果 C++
一侧的库完全使用智能指针还好一些,但这件事情高度自由,不可强求。
ABI 问题。上面提到了这种方法依赖于源语言的对象模型;但不仅如此,我们还依赖于编译器所使用的 ABI。例如,如果库是 gcc 编译的,wrapper 也需要是 gcc;甚至 gcc 的 Library ABI 的变化,也会使我们受到影响。
dotnvim 是很久之前开的坑了,当时是想做一个颜值在线的 Windows neovim 前端。但其实我很少单独使用 vim,用也多半是在别的 IDE 里面用 vim 插件,所以这个项目也没怎么更新过;而且新的 Windows Terminal 完善之后,大概 dotnvim 存在的意义又下降了一分。但今天又打开看了一下,发现颜值其实还是挺不错的,居然又燃起了我间歇性使用 vim 的欲望⚠顺便再写一遍文章回忆一下当时开发时遇到的坑🤔
没有可用的 C# neovim 客户端
虽然当时在 neovim Wiki 的 Related Projects
里面有列出一个 C# 客户端,但实际看过就会发现功能欠缺很多,几乎处于不可用的状态。所以只好自己再造一个轮子了。neovim
与前端的通信使用的是 message pack,是一种很容易理解的协议。整个客户端的实现也很简单,就是 neovim
说什么,我们照做就行了——比如光标移动到哪里、颜色设置成什么、显示什么字符之类的。