changnet

确实漏了 pb_newfield/pb_delfield 的处理，添加删除field需要把已有的的排序free掉，用到时再重新排序 内存分配这个，似乎没法避免

内存分配和排序这个我觉得可以接受，因为一般的使用场景，proto文件加载后就很少会变化。偶尔更新一次proto进行重排消耗不算大（比如游戏里进行热更新）。这个排序是用到时再排的，如果有什么特殊的使用场景，避免调用pack、unpack，那即不会分配内存，也不会排序 extension这个，我从来没用过，要花点时间去看一下才知道

补上了newfield delfield的处理。newfield、delfield是根据`field_sort`字段是否为NULL判断是否存在排序，而字段的排序是调用pack或者unpack时才会执行，应该不会对加载pb文件造成影响 不过因为字段的排序是调用pack或者unpack时才会执行，也会造成pb_sortfield执行时，需要把一个`const pb_Type*`强转为`pb_Type*`来进行字段排序，因为现有的接口不方便根据字段名取`pb_Type*`类型的指针

关于调用了gettop这个，之前的做法是用pushvalue来复制一份到栈顶，所以可以传负索引或者说不传索引，默认使用-1。现在用gettop是因为想省去做这个复制。这两种做法，我确实也有点疑问它们差别有多大，最终测出来的结果是差别太小，看不出来。如果想用pushvalue的方式，我可以改一下 命名这个，是按上一版本写的。我原本考虑是用pack、unpack，但现在pb.pack、pb.unpack这两函数是被占用了，所以之前有问一下是否考虑把现有的pack、unpack接口放回buffer和slice模块，然后这两个接口用pack、unpack。如果不改，那我可以按现有的风格改成lpbE_packmsg、lpbD_unpackmsg 换行风格这个，个人喜好吧，等上面的问题确定了我一起改一下

`static int lpb_relindex(lua_State *L, int idx, int onstack)`需要另一个参数`onstack`，要么就用现在的gettop来取，要么在对应的函数再加一个参数，或者放到`lpb_Env *e`中来维护，感觉都不算优雅。有什么其他好办法么？

1. 使用lpb_relindex替换原有的gettop方式 2. 接口名改成pb.pack、pb.unpack 3. 整理了代码风格

确实没改文档。麻烦你那边改一下

我之前一直是用的pbc，[增加部分proto3支持并且使用自己的binding](https://github.com/changnet/MServer/blob/master/engine/src/net/codec/protobuf_codec.cpp)，但是问题是pbc虽然提供了编码、解码相关的C接口，但不具备反射功能。即pbc加载了pb文件后，没有接口获取某个message里有哪些字段，是啥类型。现在pbc基本没在维护，即使自己pr新功能也未必会合并。 目前大概的想法是 1. 可以在c直接调用的encode、decode接口，以适应不同的框架，并不是所有的框架接口都是从lua调用的，例如 ```c /** * @brief 把lua table打包到缓冲区中 * @param LS lpb_State指针 * @param L lua虚拟机 * @param index 需要打包的lua table在栈中的索引 * @param buffer 用于存放编码后数据的缓冲区指针 * @param buffer_len...

> 对于第一个需求，可以考虑提供接口，但是pb终归是给Lua用的，你最终给socket也是提供给Lua具体的表的，我看不出来将读取循环放在Lua里会有什么问题。在pb.c里有创建Slice的方法，你可以用`lpb_newslice`得到一个slice，并且设置它的值，然后在Lua里传递给pb： > > ```lua > socket.receive(slice) > local pkg = pb.decode("xxx", slice) > ``` > > 也可以`pb.encode`到一个`pb.Buffer`，然后在C里处理。我没看出来有什么不方便的地方。你有什么**必须**的地方一定需要一个C接口的理由吗？ > > 对于第二个，这个几乎完全是一个全新的需求，它涉及到很多麻烦的地方（比如栈上最多255个，比如如何表达嵌套数据结构）。注意到Lua的原则**table是Lua唯一的数据结构**，你的这个需求必然是小众和有限制的。如果你有这样的需求，你可以使用底层接口（buffer, slice等），完全可以用纯Lua做到这个效果，但是性能问题你自己承担。如果要用C来实现，这个就属于为了2%的需求要写98%的代码的示例了。你可以考虑fork本项目然后自己改自己用甚至开源，但是这不是本项目支持的范畴。当然同样的，如果你有非常完善的理由说明有特殊情况必须要这种接口不可（而不是为了所谓方便或者效率？）那么我会缓慢地考虑做支持（比如按顺序encode这个需求就是提了好几年我才想到办法用简单的方式做到了支持），但是时间上就不会很快了。 从需求上来讲，并不是必须要一个C接口的，就纯粹是之前的代码结构是在C处理这一块逻辑，如果可以，那就没有必要牺牲少量性能做一次lua回调。我也并没有期望在这个库地提供一套C接口，没必要的，而是期望在有相关头文件的情况下，能自己实现。我初步做了测试，假如提供了头文件和错误回调函数，那只需要在自己的代码里使用几行代码就能实现这两个函数： ```c int Lext_encode(void* LS, lua_State* L, int...

先初步实现了根据message pack unpack的接口，如果觉得可以，可以先合并这两个接口 c api的话，我再考虑下方案。主要是现有的错误处理走的是longjump，而不是返回值。这对 `socket收到数据 --> c api --> lua` 这个流程的调用不是太友好。因为在c api之前，是没有lua_pcall的，longjump就直接跳到上一次lua_pcall的地方了