删除 lua.ByteArray 中与 Long 相关的方法

Delete some methods about Long in lua.ByteArray.

用lua实现ByteArray和ByteArrayVarint 一文中,我介绍了用 lua+lpack+BitOp 实现的 ByteArray 模块,这个模块模仿 AS3 的ByteArray,给从Flash转到quick-cocos2d-x的程序员以亲切感。

这个模块被网友们找出了一些BUG,例如 这个这个这个 ,和 这个

今天,我将这些网友提出的问题一一做了确认和测试,发现有些并非BUG,而是理解有偏差。

但有个不是BUG的问题却可能造成重大的错误,那就是:

lpack 库操作long值的时候,长度在不同机器上是不统一的。

看下面这段代码(完整代码 在此):

1
2
3
4
5
6
7
8
9
require("pack")
local l = string.pack("l", 32333)
print(#l)
local L = string.pack("L", 33333)
print(#L)
local i = string.pack("i", 32333)
print(#i)
local I = string.pack("I", 33333)
print(#I)

这段代码在不同的平台上执行得到的结果并不相同。在 Mac 平台上,输出的结果是8,8,4,4,而在 iOS 模拟器中,输出的结果是 4,4,4,4 。

当然,lpack 库的表现并非它的bug,而是因为根据 C语言标准,long的长度是 At least 32 bits in size,这就导致了 long 的长度受到机器字长和编译器的影响。

Mac 版本的 quick-x-player 采用64bit的编译器来编译,因此 long 的长度是8;而 iOS 模拟器采用的可能是32位编译器(以及CPU架构),所以 long 的长度是4.

Apple的新移动设备将采用64bit的CPU架构,但淘汰旧设备可能需要很长时间。

何况还有Android。

虽然这并非quick的问题,也不是lpack的问题,甚至不是lua和C语言的问题。但对于quick这样一个跨了4个平台(Win/Mac/iOS/Android)的引擎来说,这种表现显然是不合理的。

虽然 Windows 和 Mac 并非 quick 主要面向的平台,但我们必须考虑在这两个平台上使用 quick-x-player 开发的程序员的使用习惯。

同时,由于 ByteArray 主要用于和服务器通讯(至少在我的项目中是这样),我们也要考虑long在服务器端的不同的处理方式。

因此,我决定从 ByteArray 库中删除4个与Long相关的方法,它们是:

  • readLong
  • writeLong
  • readULong
  • writeULong

这些方法已经从我修改的 quick-cocos2d-x 中移除。我会稍后将其推送给触控。

留言

2014-07-09
次访问