@上善若水，那肯定没问题。

但还是先来请教请教，看有没有减少写入损耗的方法。

比如，如果是 inner.zip 的话，使用支持流式读取 zip 的工具（如 bsdtar 和 busybox 里的 tar），稍稍动动手写一行代码（7z ... | bsdtar ...），就能避免巨大的写入损耗，说实在是有点爽的事情。。

@都是假的，网上下的，我也没辙。。有些人还用几GB字典去压 inner.rar 呢。。（压不动，解压时还要再吃我几GB内存。。）

@上善若水，写入大小是 inner.rar 和里面的文件。我不需要中间文件 inner.rar

笔电的固态，换起来估计会麻烦（预装的分区有没有笔电自己的东西，我也不清楚）

所以能延长点寿命，就尽量延长下了

@老虎会游泳，我现在不想碰 restrict，因为：

• C/C++ 本身速度足够快，我目前不需要写性能极度敏感的代码
• 弄清楚编译器如何对待 restrict 估计很耗时间。。

cppreference - 求值顺序 说：

除下列标出者，任意 C 运算符的运算数求值顺序，包括函数调用表达式的函数参数求值顺序，及任何表达式的子表达式求值顺序都是未指定的。编译器会以任意顺序对其求值，而且在同一表达式被再度求值时可选用另一种顺序。

C 中没有从左到右或从右到左求值的概念，这不会与运算符的从左到右或从右到左结合性混淆：表达式 f1() + f2() + f3() 被分析成 (f1() + f2()) + f3() ，因为 operator+ 的从左到右结合性，但运行时对 f3 的函数调用可以最先、最后，或在 f1() 与 f2() 之间求值。

未定义行为

1. 若对一个标量对象的副效应与另一个对同一标量对象的副效应相对无顺序，则行为未定义。

i = ++i + i++; // 未定义行为
i = i++ + 1; // 未定义行为
f(++i, ++i); // 未定义行为
f(i = -1, i = -1); // 未定义行为

2. 若一个标量对象上的副效应与另一个使用同一标量对象之值的值计算相对无顺序，则行为未定义。

f(i, i++); // 未定义行为
a[i] = i++; // 未定义行为

3. 只要至少一个子表达式的排序容许这种无顺序副效应，就应用上述规则。

我记得，C 只保证在序列点后，所有副作用都被执行。

@水木易安，呃。。我的意思是，这些都只是 C 语言的（关键字级别的）基础内容。

只不过有点偏，连老虎写了多年 C++ 代码的都没注意（我也只是最近写 C，查语言标准，看自己代码能不能这样写时，偶然注意到）

我们的课程没有 8086/x86/x64/arm/wasm/... 汇编。。我只是凭以前看过的半本 x86 汇编，和老虎聊上一两句而已。。

这个帖子好像没涉及到编译原理中的词法语法分析，有谈到编译器，但也仅是猜测它的行为

@老虎会游泳，是的。但有时候也教 UB 代码，比如 i++ + ++i 啥的

@水木易安，不会吧？我记得理工科的都要学 C 啊。。

@水木易安，其实，这是大一学的 C 语言里的内容。。但我最近才重新注意到它。。

但看起来，写商业 C++ 代码的老虎，这么多年都不熟悉这个，看来是没啥用的特性

好像没遇到过。蹲个后续。

@老虎会游泳，最后居然聊了这么远。。扯到汇编去了（但 C/C++ 本来就和底层接近，谈及汇编来理解 C/C++ 行为，似乎也很正常。。）

老虎你写商业 C++ 代码的，都不知道 restrict，看来 C/C++ 的效率足够绝大部分场景使用，是我杞人忧天了。

@老虎会游泳，噢，是我想错了 编译器认为 this 没被改，但 this->target 可能被改了。。

x64 时，this 作为第一个参数，存在 rdi 中？

@老虎会游泳，this 符合【完全优化至寄存器的条件】吗？我记得是只读的啊。。那篇文章里，也没有要 &this。。

@老虎会游泳，我能看懂一点点汇编，你说的我能理解。（看过半本墨绿色的 x86 汇编书，但没咋写过，又都忘得差不多了。。）

@老虎会游泳，不对，你看看 知乎那篇文章 提到的第三个例子，

修改了 this->target 的值（unsigned char 类型），导致编译器认为 this 也可能被修改了，所以后续每次 this->target 都要重新读取 this。。

（我记得 C++ 的 this 是只读的？还是啥？编译器咋会认为被修改了呢。。）

@老虎会游泳，意思是，拿某个寄存器来存 read_next，而不存入栈上了

好像写入数组末尾之后，是未定义行为。这么说，编译器认为 read_next 未被修改也无不可。。

哎，还是等写完之后，再加 restrict 试试吧。反正也不是啥速度极为严苛的场景，只是想顺便学学 restrict 而已

@老虎会游泳，

指针本身是否被优化到寄存器与restrict无关。如果不对指针进行取地址操作，它就可以被优化到寄存器。

char buf[16];
char *read_next = buf, *write_next = buf + 16;

*write_next = '\0'; // 此时 read_next 岂不就被修改了吗？（假设 read_next 就在 buf 后面）

编译器咋会放心把 read_next 缓存至寄存器的。。

@老虎会游泳，老虎用 restrict 的情景多吗？

我是不是要写完那个小插件，再试试加 restrict，才理解得更快呢。。

@老虎会游泳，感觉 43 楼的设计，没法加 restrict？

那岂不读指针和结束指针都没法缓存至寄存器，每次读取前都要读一次内存？（因为编译器认为，写指针可能会修改 char *read_next, *end？）

@老虎会游泳，画了个草图，容易理解：

@老虎会游泳，写指针 和 读指针，都指向同一块缓冲区。只是写指针写入过后的字符对象，都绝不再读取。（因为写指针不会超出读指针，如上所述）

@老虎会游泳，只是【通过 char * restrict 修改后，不再使用其他别名】，也不行？

因为解析了一个字符，并写入后，就不再需要读取这个及之前的字符对象了

@老虎会游泳，“对象类型”是指非函数类型。。

另外，只是指向 char 类型的读写指针。

另外，根据严格别名说的，char * 可修改任何类型的数据。

所以，我认为给 char * 添加 restrict，可防止【写指针写入数据后，编译器认为所有指针的数据缓存都失效不能用了，需要重新读取】。

不知这个想法对不对