@L4Linux
@wdhwg001

乍一看没什么特别的，但这不是 consteval 函数，是 coroutine.
想象一下有栈协程和动态类型的解释型语言此时在干什么（看向 v8 ）。
能把并发函数优化成常量说明这个「协程」甚至不是状态机（编译器很难优化状态机），而是直接计算了 cps 变换后的结果，这就很 amazing 了。


可以看看 cppcon2016 的那个视频，当你先写了一段 sequential 代码，再改成异步，再改成 coroutine ，再把优化一开
——
boom ，一个常数！

跟魔术一样，performance makes a trick being real magic.

从 ppt 和我一点实验来看，现在的基础设施还不能把 coroutine 优化得特别好，起码还没达到 presentation 展示的最佳效果，标准库也还没跟上。等标准库完善之后编译器应该能更好地优化，从 presentation 来看，能优化的东西是有很多而且很有效的，未来可期。（指 c++26 以后）

合理，但你举得例子不太合理。

首先不是所有的岗位需要掌握的基础知识都一样，除非你想考察的基础知识就是算法，那另说。

进制转换这种教科书第一章第一节的示例题，答出来也说明不了什么，也不是个好的展开点。你也许想考察 CPU 相关的知识或者浮点或者格式化字符串输出，但从进制转换开始都很生硬。为考而考。

第二个例子就更加为考而考了，硬件和软件考虑的领域完全不一样。假设你想考高级语言语法树到机器码到 CPU 硬件加法器的全实现，那其实只问「写下这行代码到输出结果发生了什么」也是可以的，为什么要先问怎么实现加法器呢？

加法器可以由不同的逻辑门构成，但你知道为什么要选用特定的逻辑门来做吗——是集成电路印刷工艺的限制，材料、印刷难度、功耗、成本等。如果我需要考虑集成电路用什么逻辑门，要么我考虑的是前面讲的这些东西——这与你要考察的核心内容相去甚远；要么我在做一道没什么实际意义的智力题。

面试不是知识展示，而是能力考察。你知道他知道更多东西的目的是确认他能做更多的东西，你并不需要确认你需要做的东西以外的所需知识。

举个实际点（但其实也不是很有意义）的例子： /t/860741
我可以通过「为什么会输出乱码」考察 unicode 的码表、编码、平台相关实现、语言相关实现、unicode 库的使用经验、内存安全性、web 安全（ utf7 ）等等知识，它们都可以从乱码这个话题展开，而且编码转换、操作系统适配、内存安全、web 安全都是比较实际的话题。


----

题外话，学生时代都有种「做题优越」，因为学生时代的竞争力完全体现在解题上，而不论题目本身是否有价值。
以后你会发现竞争力来自于「给事物赋予价值」，是很不一样的。

告诉几件 OP 无法理解的事：

1. 只有你自己才知道你有两台设备，其它人不知道。
2. 只有你自己才知道你把验证器装在了哪台设备上，其它人不知道。
3. 只有你自己才知道登录验证的 require 弹窗和 confirm 弹窗弹在了哪台设备上，其它人不知道。


> 就因为安卓备用机登录了账户，死活必须让验证 → 这是正常逻辑
> 那你还弹出 TOTP 让我验证干叼 → ？
> 都关机半月了 → ？
> 本机也没暂停过使用服务 → 本机？是说这个备用机不是「本机？」那什么东西关机半个月，和暂停有关系吗？怎么就智障了？
> 如果 TOTP 不能作为验证手段，那就关了吧。→怎么就不能了？
> 而且开机的 IOS 就这么视而不见？？→ ？？？ 哦意思是「本机」是 IOS 是吧，那非本机登录要求验证哪智障了？

----

抛开逻辑破碎不谈，难道不是 A 设备登录->B 设备打开验证器->A 设备输入 B 设备获得的验证码就好了吗？

我只能猜测是你 B 设备打开验证器这步遇到了问题，但你从头到尾的追加都没提到相关信息
那我只能认为也不是这一步
但登录和输入都不可能有问题

于是我推断 OP 想等 confirm 弹窗但是 B 设备就是不弹，他就是不肯用输入验证码这个方式或者没有这个方式，结合最后一个追加的图上有显示「使用验证器获取验证码」，那排除没有这个方式；


结论只能是

OP 想等一个 confirm 弹窗，但 B 设备也就是他的主力机 ios 设备，没有弹，于是他认为 google 账户验证很智障。

@James369

你的理解有误，tag 就是指向具体 commit 的标签，跟在哪个分支无关

master 分支的目的是公共 checkpoint ，包含每一个完整的 feature ，与之对应的是 dev ，会包含尚未完善的 feature 。master 上每一个 checkpoint 或者 merge 点代表完成一个完整 feature 。

release 分支会有很多个（ release_v1, release_v2 ...），它们与 master 永久分岔，目的是存放所有已发布的历史线，如果不需要对外提供旧版本的 release ，那么旧的 release 分支其实可以删掉。之所以分岔的原因是，master 会有新 feature 和新 fix ，但 release 上只会有新 fix ，历史与主线是不同的。release 上的 fix 一般通过 cherry-pick 获得

如果完全不需要对已发布的版本做修复，而采用修复随版本滚动提供的方式，那么完全不需要 release 分支，只需要 tag/release 就好。 tag 的作用是给 commit 做特殊标记，由于有意义的 commit 一般在 master 上，所以 tag 「碰巧」打在了 master 上

@unt
杜绝相互合并，尤其是双向三路合并（ git merge ），即 a merge b, b merge a ，which is extremely evil ；
严格遵循单一公共线原则，即使是 feature 分支，也要有公共的 feature 分支+feature_a_dev+feature_b_dev ；
推送代码前必须先拉代码;
严禁任何分支 mege master ，只允许 master merge dev

推荐在 feature 和 dev 分支上禁用 merge ，只允许 rebase 。但 rebase 会导致目标分支历史重写，所以有第二条，尽量只重写自己的分支，避免公共分支被重写干扰其他人

我有个印象，可能记错别太当真，就是，golang 会把函数内所有变量和参数都复制到栈上，所以可能只要 sp 指回来整个栈帧就能恢复

@Doracis rebase 到 3 个 commit 前出来 19 条没遇到过，但猜想是你 rebase 的目标经过了一个 merge commit ，导致历史混乱。应该先把 merge 后的 commit 暂存（ cherry-pick 到临时分支或者 stash 起来），reset 掉 merge commit ，然后再重新 merge ，再 pick 回暂存的东西

提示 allow empty 常见场景是你从 A 分支分岔开发 B 的时候发现有个 A 的 bug 要修，然后你在 B 上提交了一个 a(1)，并且把这个 bug 告诉了其他人，它们也在 A 上提交了一个 a(2)，当你要 rebaseA 把 B 的历史接到 A 后面时 a(1) 就是个空修改，因此可以直接舍弃掉。还有一种常见是 a(1)和 a(2)发生了冲突，你解决完冲突临时 commit 的修改与 a(2)相同，临时 commit 就变成了空的，也可以跳过

翻出来一张图：
https://i.imgur.com/eEGW6xW.png

@iikebug 你写过招投标材料不

@lichao 生产环境放 windows server 然后用 wsl 管理（🐶

------

wsl 被称为最好的 linux 发行版的原因是整个 windows 是它的一部分🐶
什么虚拟机，大家都是 hyperv 里的子系统，windows 内核并没比 wsl 内核高出一等🐶

只要这个程序（或 docker container ）能在本机上跑得起来，我一定会首先尝试 dlv

本来还想说我 windows 遇到过重启好了

macos……




总之先重启（

@potatowish 你想的是「代码都看得见没后门就用啊」，人家想的是「我想加后门的时候发文件也不管用怎么办」

你好，编译器顶多能理解语法，它们绝大多数情况下不理解 on 和 get 是什么语义。

a.b
a.b

后面的 b 覆盖了前面的 b ，这是一个纯语法问题

a.b
a.c

c 和 b 是不同的语义，我怎么知道 c 会覆盖 b ？不太可能吧

@duke807

rust 不如说是 c/++ 专家在被内存惨虐才创造出来的……

c++本身就很难写得对，又是语法怪物，又是工程陷阱，放在今天来看简直可以说一无是处，rust 为 c++提供了一点改进，好解决的工程陷阱先解决了，语法怪物和正确性问题解决了一部分，已经很不错了。

别的语言 <name> <get|install> <module name> 三分钟工程 setup 好了，c++调试跨平台 cmake 脚本花了我一整天，气得我想笑，谁还愿意在 2022 年为了构建项目手写脚本拼编译器开关字符串呢

我想用 rust 正是因为我知道智能指针怎么实现，但一个线程安全又解决了循环引用的智能指针实在太难写对了，我想有封装好的基础设施，并且我也不想每个变量都多套一层没用的 wtf_pointer<T>，你看，有语言给我封装好了

这跟工程陷阱问题一样，对任何人来说都是徒增心智负担的东西，我相信大多数追捧 rust 的群体是受够这些泥潭的人，而不是看着新鲜又没能力写那些「学术化内存代码」的人。


------


想告诉 OP 的是，rust 这些「独特设计」都是 c++某些机制的高级抽象版或者封装版，它们这么复杂是因为实现这些抽象的更基础的设施还要更复杂，复杂到接近人类智能能处理的极限且无益于工程化，相比之下 rust 的代价已经减少很多了。c++可能是慢 10 倍，rust 慢两倍……

*末代 intel mbp

x86 cpu 都差不多，我的末代 mbp -j8 编译，温度也差不多 10 秒破百

试试 git-fsck