lodash 中的对 Buffer 的深拷贝为什么用 slice 函数https://github.com/lodash/lodash/blob/master/.internal/cloneBuffer.js#L25 从 Buffer 的官方文档看http://nodejs.cn/api/buffer.html#buffer_buf_slice_start_end slice 函数返回一个新的 Buffer,它引用与原始的 Buffer 相同的内存,这样的结果不是浅拷贝么? 我的理解是这样才对
function cloneBuffer(buffer, isDeep) {
if (!isDeep) { // 这里加上!
return buffer.slice()
}
const length = buffer.length
const result = allocUnsafe ? allocUnsafe(length) : new buffer.constructor(length)
buffer.copy(result)
return result
}
求解答
1
Caballarii 2019-09-16 13:27:48 +08:00
自己去试试不就知道了,信书还是信运行结果?
|
2
momocraft 2019-09-16 13:34:38 +08:00
https://github.com/lodash/lodash/commit/ce60ac42747a0997335c16e858e3e654c409dc8c
这时候还有的,不知为什么现在没了,也许你可以追查一下 |
3
ysc3839 2019-09-16 13:39:19 +08:00 via Android
没问题吧? if 后面是 not isDeep,那用 slice 浅拷贝有问题吗?
|
4
justfly 2019-09-16 13:41:05 +08:00
if (!isDeep). 翻译翻译
|
5
shintendo 2019-09-16 13:42:31 +08:00
楼上两位眼科
|
6
a494836960 2019-09-16 13:46:17 +08:00
好像没看出啥问题。。
|
7
123s 2019-09-16 13:46:37 +08:00
4 楼正解
|
8
Melting 2019-09-16 13:59:18 +08:00
看 node 文档的意思,深拷贝用 copy 浅拷贝用 slice,大概率是 lodahs 有问题吧
|
9
mcfog 2019-09-16 14:14:29 +08:00
复现: https://repl.it/repls/PracticalPleasedConferences
deep 的行为完全反了,也许根本就没有人用 lodash 来 clone Buffer 对象吧,本来 node 环境用 lodash 的就少 > https://github.com/lodash/lodash/commit/ce60ac42747a0997335c16e858e3e654c409dc8c 有趣的是这个 bug 的引入和楼上贴的引入这个 feature 的 commit 是同一天,在补充了(错误的)单元测试的同时,把这个条件翻转了 |
10
mcfog 2019-09-16 14:16:12 +08:00
|
11
shintendo 2019-09-16 14:22:10 +08:00
666,楼主赶紧去提 issue
|
12
Karpov 2019-09-16 16:45:33 +08:00 via iPhone
该方法中没说这个 buffer 是 node 的 buffer,没有证据表明支持。多数情况下这个 buffer 指的是在浏览器下传入的一个数组。
也许楼主可可以考虑作为增强功能提交代码使其支持 node 的 buffer。但是这样涉及到的判断和代码都不少,感觉也不太好修。 |
13
Karpov 2019-09-16 16:54:23 +08:00
好吧 再继续研究一段时间后 我不得不承认 这是个 bug 了···
|
14
banxi1988 2019-09-16 17:01:13 +08:00
楼主细心了,赞.
原实现应该是有 Bug, 少写了一个 ! 号. |
15
Karpov 2019-09-16 17:22:21 +08:00 via iPhone
单员测试也能被反转也是太秀了,估计那天受刺激了故意留的后门
|