今天整理了一下项目中使用的第三方框架、库的列表，很多，有C++的，有Lua的，突然面临一个迫切需要解决的问题：怎么决定某个功能应该由C++实现还是由Lua实现？
最早决定让项目成为一个由C++构建主体框架，由Lua脚本扩展实现其他的业务逻辑时，只是单纯得想让C++完成一部分最核心的功能。但现在的问题是，怎么判定一个功能是否够核心，以及即使够核心了，还得考虑其他一些因素，包括实现难度，安全保护，代码架构合理性，代码和逻辑共享等。
众所周知，用不同的语言实现相同的功能，难度和工作量可能差别很大。以前听同事和领导不止一次说起过，一行脚本顶得上一百行C++代码。这也许有点夸张的成分，但正好说明差异巨大这个事实。引起这种差异的主要原因就我自身角度出发来看，在于对语言的掌握程度，不同的语言风格就对不同开发任务的适应度，以及可利用的现成的库和代码的丰富度和成熟度。
说起安全保护，是今天看到Lua的maillist上讨论LuaJIT时Mike Pall说起源代码保护时才提醒了我。一般说来，用C++编写的代码，经过编译生成二进制代码，比起用脚本语言写的代码生成的字节码（中间码）反编译要困难得多。而我本来考虑让众多功能都通过脚本实现，这就面临一个问题，如何保护自己觉得重要的代码。最早的时候想用Lua的官方编译器编译一把就行了，现在看来这个保护弱得可以。而最近又面临另外一个短期内不可能解决的问题是，我打算嵌入LuaJIT 2.0的解释器，而刚刚才知道LuaJIT 2.0不兼容Lua官方的字节码，只提供源代码级的兼容，似乎LuaJIT也没提供一个自己的编译器，同时即使有这样的编译器，万一某种情况下需要用Lua官方编译的文件，那么处理就不一致了！Mike Pall的意见是，用个zip之类的东西打包加密就行了，呃，怎么说，确实是个方案，但使得本方案只能自己使用的了，不能让第三方的开发者参与了！所以除非有其他比较完善的解决方案，不然那样的代码只能用C++实现了。
再说架构合理性，总的说来，到目前为止的进度，自我感觉这样的架构还是比较满意的，当然现在只是一个空壳，只能支持让主菜单、工具栏按钮和右键弹出式菜单的构建和触发都是由脚本插件扩展而成，接着就而对的问题是，像配置选项功能要由谁来做，这种功能有一定的复杂性，又有GUI界面，又有后台处理逻辑，是全部让C++做，还是全部让Lua做，或者是各做一点，那又是各做哪些和各做多少呢？几乎所有同时涉及界面和后台逻辑的功能点，都有这样的问题，究其原因在于，用C++实现了主界面，而在Lua中目前并不能很方便地操作这些界面。原本天真地以为，C++用了wxWidgets做界面，那么Lua中用wxLua就可以实现无阻碍互通了。现实是残酷的，现在光是想让wxLua中使用C++中创建的主窗口作为父窗口就搞不定！
最后是代码和逻辑的共享。这个问题不是很严重，如果是纯粹的计算逻辑最容易共享，一些常用的底层功能，两种语言都差不多拥有第三方库来解决。除了GUI，其他的代码（逻辑）要共享，通过luabind和SWIG可以比较方便地粘合起来。如果粘合起来还是犹豫不决，那就是架构合理性的问题了。
想不到这次决定构建一个基于C++的脚本扩展框架的应用程序，会引出这么多问题，大大出乎我的意料啊，我是一直以来对风险的估计不足啊！
支付宝扫一扫
微信扫一扫