@无名啊，Linux的unrar也可以流式调用：

sudo apt install p7zip unrar
7z e -so test.7z.001 inner.rar | unrar x -si -o"+" .

-so 解压到标准输出
-si 从标准输入读取压缩包
-o"+" 解压时覆盖所有已存在文件（没有该选项，文件重名时会退出）

@艾木友尔尔巴，发现局域网内的其他设备

@无名啊，嗯，看起来C为并行执行优化留下了很多空间。

@无名啊，i++ + ++i中哪一部分是未定义的？C标准允许++i读取不到i++增加后的值？

@无名啊，我看出一些问题。
restrict是一个C99规定的关键字，C++的任何版本都未要求实现该关键字，大部分C++编译器会直接忽略它。
你是想在C++中用它吗，那你应该用__restrict__，虽然它是编译器特定扩展，但大部分编译器都实现了它。

浏览器已经开发了多种功能来阻止这种操作。在浏览器的默认隐私策略中，应该获取不到任何全局唯一标识。

操作系统也在努力避免通过IPv6地址暴露网卡mac地址给网站。

最初的全局唯一IPv6地址要求通过mac地址转换生成，同一设备在不同网络下生成的IPv6地址后缀都相同。后来发现该特性被网站滥用，用于追踪用户，于是发布了IPv6隐私扩展。

支持IPv6隐私扩展的操作系统会在连接时优先使用随机生成的IPv6地址后缀。

@无名啊，@水木易安，大学肯定不会教这个啊，大学教的C和C++基本上都是最具可移植性的部分，语法基本上停留在C89阶段，不会有C99之后的新特性。

@残缘，你可以试试：

ndp -an
arp -an

@希望自己长胖胖，LED很省电的，没有LED功率要求不会变小吧

可以采用webrtc+p2p来进行播放，可以节省带宽流量。
例如：
http://www.hifilm.top/film/tv?media=http://cctvalih5ca.v.myalicdn.com/live/cctv15_2/index.m3u8
可以把上述网址中的media值改为其它m3u8网址

@admpub，它能实现类似BT下载那样的自动互传吗，看的人越多越流畅？

---

相关开源项目：

• https://github.com/cdnbye/hlsjs-p2p-engine/blob/master/Readme_zh.md

P2P技术使观看相同内容的用户之间可以相互分享数据，不仅能效降低视频/直播网站的带宽成本，还可以提升用户的播放体验，降低卡顿、二次缓存的发生率。 另外，随着H5的普及，flash逐渐被淘汰已成为不可逆转的趋势。而在H5采用的视频传输格式中，hls由于兼容ios和android、可以穿过任何允许HTTP数据通过的防火墙、容易使用内容分发网络来传输媒体流和码率自适应等众多优势而在业界得到广泛使用。通过使用hls.js这个第三方库，几乎所有现代浏览器都可以播放hls视频。hls天生分片传输的优势，使其可以采用p2p的方式进行传输，从而减小服务器的负担。在web端，无插件化实现p2p传输能力的最好选择就是WebRTC技术，与hls.js类似，WebRTC也支持几乎所有现代浏览器。本项目是一个hls.js的插件，通过WebRTC datachannel技术，在不影响用户体验的前提下，最大化p2p率，是面向未来的Web P2P技术。

• https://github.com/cdnbye/CBPlayer

CBPlayer 是基于 DPlayer 开发的，内置 CDNBye P2P 插件的 H5 播放器，加入了记忆播放等实用功能，右键可以查看p2p实时数据。支持HLS、MP4和MPEG-DASH三种格式的P2P加速。

相关讨论：内网用户同时看同一直播，怎么保证流畅
https://hu60.cn/q.php/bbs.topic.102308.2.html?floor=36#36

@admpub：

可以采用webrtc+p2p来进行播放，可以节省带宽流量。
例如：
http://www.hifilm.top/film/tv?media=http://cctvalih5ca.v.myalicdn.com/live/cctv15_2/index.m3u8
可以把上述网址中的media值改为其它m3u8网址

相关开源项目：

• https://github.com/cdnbye/hlsjs-p2p-engine/blob/master/Readme_zh.md

P2P技术使观看相同内容的用户之间可以相互分享数据，不仅能效降低视频/直播网站的带宽成本，还可以提升用户的播放体验，降低卡顿、二次缓存的发生率。 另外，随着H5的普及，flash逐渐被淘汰已成为不可逆转的趋势。而在H5采用的视频传输格式中，hls由于兼容ios和android、可以穿过任何允许HTTP数据通过的防火墙、容易使用内容分发网络来传输媒体流和码率自适应等众多优势而在业界得到广泛使用。通过使用hls.js这个第三方库，几乎所有现代浏览器都可以播放hls视频。hls天生分片传输的优势，使其可以采用p2p的方式进行传输，从而减小服务器的负担。在web端，无插件化实现p2p传输能力的最好选择就是WebRTC技术，与hls.js类似，WebRTC也支持几乎所有现代浏览器。本项目是一个hls.js的插件，通过WebRTC datachannel技术，在不影响用户体验的前提下，最大化p2p率，是面向未来的Web P2P技术。

• https://github.com/cdnbye/CBPlayer

CBPlayer 是基于 DPlayer 开发的，内置 CDNBye P2P 插件的 H5 播放器，加入了记忆播放等实用功能，右键可以查看p2p实时数据。支持HLS、MP4和MPEG-DASH三种格式的P2P加速。

@ywm123，我也这样，还不知道怎么修复

@㝶芾厶眵攴䭡，回报率提高，游戏内灵敏度就需要降低，否则移动速度就会过快。

编译器认为 this 没被改，但 this->target 可能被改了。。

其实这句话没说错：

因此，每次修改 target，编译器认为 this 也可能随之变化，即 target[0] = t & 0x7; 可能改变了 this 指针。

因为this（也就是RDX寄存器的值）可能变了，所以才需要重新加载this->target。

那为什么不需要重新加载this呢？因为它就在寄存器，所以自然不需要重新加载，直接用就好了。

@无名啊，关于

老虎用 restrict 的情景多吗？

我以前不知道restrict和“严格别名”，今天刚知道。我以前唯一了解的所有权转移情形是std::move()。

https://blog.csdn.net/xkdlzy/article/details/108873014

小于等于64位的整型或指针类型返回值由RAX传递。
浮点返回值由XMM0传递。
更大的返回值(比如结构体)，由调用方在栈上分配空间，并有RCX持有该空间的指针并传递给被调用函数，因此整型参数使用的寄存器依次右移一格，实际只可以利用3个寄存器，其余参数入栈。函数调用结束后，RAX返回该空间的指针。

但函数没有返回值（void），所以不清楚上面的案例中RCX用于什么，x64调用约定没有明说。

@无名啊，上面的代码：

因为target是struct T的第一个成员，所以它的首地址就是this。也就是说，this在rdx寄存器。

x64调用约定：

整数参数在寄存器 RCX、RDX、R8 和 R9 中传递。

所以this既然在RDX中，那么它应该是第二个整数参数，第一个可能是返回地址。

@无名啊，对了，VC++的__thiscall调用约定始终将this指针放在ecx寄存器。

https://learn.microsoft.com/zh-cn/cpp/cpp/thiscall?view=msvc-170

__thiscall 的调用约定用于 x86 体系结构上的 C++ 类成员函数。 它是成员函数使用的默认调用约定。

在 __thiscall 下，被调用方清理堆栈，自变量将从右到左推送到堆栈中。 指针 this 通过寄存器 ECX 传递，而不是在堆栈上传递。

@无名啊，this可能已经优化到了寄存器中。

T::unpack3bit 每次移位之前都重新获取 target 变量的地址放到 rdi 中， mov rdi, QWORD PTR [rdx] ，而 target 整个过程没有改变，这样做没有必要。

这里是在读取target指针的值，mov rdi, QWORD PTR [rdx]，是以rdx寄存器的值为内存首地址，连续读取8字节到rdi寄存器。

因为target是struct T的第一个成员，所以它的首地址就是this。也就是说，this在rdx寄存器。

所以问题是程序一直在从内存加载this->target，而非一直在从内存加载this。