opt: encoder support Uint64ToString and Int64ToString#723
Conversation
|
|
AsterDY
left a comment
AsterDY
left a comment
There was a problem hiding this comment.
你这个只支持了非x86下的实现，x86需要在encoder/x86中实现哈
|
|
||
| // Int64 or Uint64 into strings on Marshal | ||
| Int64ToString bool | ||
| Uint64ToString bool |
|
统一用json.Number不行么？ |
目前看，不太行，下游传递回来的数据结构千奇百怪的，decode到一个map[string]any里； |
period331
changed the title
period331
changed the title
|
糟了，go1.17，没有any，我改下 |
| NumberStr: "46", | ||
| }, | ||
| want: `{ | ||
| tests := []struct { |
| EncodeNullForInfOrNan bool | ||
|
|
||
| // Uint64 into strings on Marshal | ||
| Uint64ToString bool |
There was a problem hiding this comment.
为啥不需要Int64呢？我的意思是Int64和Uint64都用一个选项控制就行了
There was a problem hiding this comment.
😓😓，我们是PHP(c++扩展)迁移go的，老逻辑只处理了uint64，int64没处理。如果同一个选项控制，会有大量diff😅
所以我给分开了，10多年的老代码了，diff太多迁移成本剧增🤡
There was a problem hiding this comment.
@AsterDY 你看可以不？要么两个选项，要么只有一个uint64的选项，如果合并到一起，我们这边就用不了了😂😂😂
| p.Add(ir.OP_bool) | ||
| case reflect.Int: | ||
| p.Add(ir.OP_int()) | ||
| p.Add(ir.OP_int(), ir.OP_i) |
There was a problem hiding this comment.
这里没看懂，应该没必要加这个CompactOp。在具体的 OP_i64读取flag bit或IsMapKey()进行处理就行了
There was a problem hiding this comment.
因为vm里是用uint64的逻辑处理int的，如果没有compatOp，则会把int也处理
There was a problem hiding this comment.
底层的OP int和uint都是分开的，这里肯定是不需要的。“vm里是用uint64的逻辑处理int的”
vm代码里面明明是分开的，不知道你指的是啥
There was a problem hiding this comment.
底层的OP int和uint都是分开的
vm里确实是分开的，但是vm里Add时，调用了这样一个函数：
func OP_int() Op {
switch _INT_SIZE {
case 32:
return OP_i32
case 64:
return OP_i64
default:
panic("unsupported int size")
}
}
uint也有类似处理，这相当于int用int64、uint用uint64的相关函数来处理了
如果没有CompatOp的话，在int64/uint64的相关处理函数内，就不知道处理的是int/uint了
还有别的地方做差异化处理了吗？
There was a problem hiding this comment.
uint也可能会导致溢出，为啥不支持这个选项？我觉得这个选项只考虑uint64不合理
|
|
||
| func (self *Assembler) _asm_OP_u64(_ *ir.Instr) { | ||
| func (self *Assembler) _asm_OP_u64(i *ir.Instr) { | ||
| if i.CompatOp() == ir.OP_i || i.IsMapKey() { |
There was a problem hiding this comment.
同上，没看懂i.CompatOp() == ir.OP_i的意义是什么。而且和vm的实现逻辑也不一致
There was a problem hiding this comment.
而且和vm的实现逻辑也不一致
实现是一致的，只是判断方式不同。
不过也有可能是我不太会asm开发，完全是临时抱佛脚，参考_asm_OP_empty_obj函数写的
period331
left a comment
period331
left a comment
There was a problem hiding this comment.
再发起一下评审，关于Int64和Uint64的选项问题，辛苦给予答复，谢谢啦
|
@AsterDY 另外我看1.23.4版本中，decode的测试有报错，但看着和我的变更无关；可以帮忙看下吗？ |
|
Do you mind speaking English? Please note I'm not asking to use my language while you are using yours. I'm French and I would like to be able to follow the discussion. English is simply more widespread. Bonne journée les amis 😁 |
period331
changed the title
4 participants
有很多时候输出给前端的数据，包含uint64类型时，在js里会丢失精度；
且下游传递过来的数据结构不可枚举，所以将给前端的数据中，统一将uint64转成字符串