见 #8 的标准方法

然而这个方法不是用来传你理解的数组的，这个传数组引用的方法几乎都发生在 constexpr / consteval 场景中，传入普通的「静态大小」（而非「编译期计算」） array 会导致实例化出大量一次性代码，严重增加目标可执行文件的冗余



以你现在刚开始入门的阶段建议先好好啃啃 c++ primer ，以前觉得 primer 上来就是模板库太抽象了，但现代版本的 c++ 确实就是大量依赖模板打造的编译期约束上的。

这老哥挺有意思

「大家快看我买的这个酷炫的域名多酷炫！」

怎么没人提 validator 呢

struct tag 就是设计来简化这坨没必要的 if 判断的

我的经验是无论遇到什么客服你直接说我要求工单提升，你别跟我讲，我要找你上级


低 level 的单子都是自动处理的，客服也没权限介入，你得一直投诉到有权限干预自动流程的等级才行

3200w 就是 16A 的插座/线

其实这些家用电器的功率都是充分设计过的，不然为啥都是 2100w / 3200w ，都是顶着家用电线的规格来设计的。接空调的线就行

草，看到这个帖子才想起来我的 gv 也过期了，一看还好能 reclaim 回来

telegram 实体卡我也被封过，邮件投诉一下解完就再没封过了

@sankooc 这种东西做起来倒是不难，不过淘宝搜了一圈还真没卖的。 假如做一个这样的产品，你觉得自己肯出多少钱来买？

几百毫秒，完全没有必要。用户空间的高精度定时器都能轻松达到 1ms 的精度，用 RDTSC 之类的指令手搓也能完全控制到 10us 级的精度。 不知道你是要怎样记录何种硬件数据，假如 gpio 之类的，像树莓派甚至 sleep 然后 read sysfs 都够了。

红烧也可以的。

羊肉处理要点其实就三大步，三步齐全就不会难吃也不会有膻味了：

1. 姜葱酒焯水（冷水下水），排出血水，酒挥发过程中也能带走一部分膻味
2. 用葱姜油爆炒一遍，高温能去除绝大部分异味，一般会再放点香料，茴香八角白芷白蔻之类的
3. 高压锅压一遍，带皮要 40 分钟以上，羊排可以时间短一点。压完之后肉质就很酥烂入味了。

广东这边的羊肉煲有清汤的有浓汤的，浓汤就在第二步放点酱和耗油炒，清汤就油炒完直接移锅加汤料，都挺好吃

我上高中时搜过这个问题，答案是用 windows server 2003 的 rdp dll 替换掉 xp 的……

但是 win server 版的 rdp 只是支持多 session 而已，并非两个连接共用同一个会话。所以也做不到「看到别人操作电脑」。


所以现在都用远控来满足这种需求了

@chanChristin EXACTLY. 组织一个让大家都满意的游戏正是「社交活动」其本身。

@murmur 只能说很符合 コメント 被阉割掉的雀魂国服玩家的心理状态…… 「锻炼社交」本来就是把聊天从「尬聊」训练成「谈笑风生」的练习

看了大家的评论…… 我有点难以想象连 「 party 聊天 game 」都感到厌恶甚至恐惧的人社交能力是什么水平🤐

桌面游戏确实是增进社交的好方式，狼人杀这种甚至不需要道具和预先准备的类型更是个中翘楚，随时随地随便一群人就能玩得起来。 我十分不理解什么都要视为 pua 的人的思路，那些个套路是大量固定规则无数人迭代后的最佳策略，那你在玩的过程中可以教、可以解释为什么要这么打、可以打圆场说我们都不会不用那么追求最佳策略，这些全都是

> 锻炼社交能力


的过程，这个标题并没有什么该反对的点啊 。

题外话： 贵公司官网居然连 SSL 都没

另，有社招 HC 吗

https://www.zsythink.net/archives/1199

收藏了快 10 年了

多提一嘴： á é í ó ú 这样带重音标注的字母/单词/语言，它发音的正确方式就是这个音节音调更高。

哈……？？？？？
这么多年我才第一次意识到这么多人搞不清重音是咋回事





超简单： 频率更高的那个音节是重音。不信你自己频谱分析一下。

我有个猜想不一定对…… 这个分辨音节频率高低的能力是不是与音乐素养有关🤔

所有 PC 系统所有手机系统所有厂商都有自带的 memo 软件，你随便用一个其实都大差不差。

我用的是 google keep ，因为很多年之前我用着的最喜欢的手机是 nexus5 ，从那时候固定下来的

排除 merge.

merge 绝对不能在双向相互合并的两个分支上进行，否则大概率丢代码。 双向相互合并是指同时存在 D->M 与 M->D 两个方向的合并（ merge. cherry-pick 会产生不同 hash 的 commit 所以不会踩三路合并丢代码的坑）


一般这种岔出去比较远了又想统一回来的场景最好的方法是 squash + 重新分岔，但有个缺点是历史可能会丢（因为重新分岔后新的 dev 或者新的 main 就不是原来的了，在非直属继承的那个分支上只能看到一个很大改动的 squash commit ）不过 git flow 发展到你现在这个场面就是没严格遵循或根本就没定好清晰的规范导致的，所以大概率历史对你们来说也不是那么重要，squash 掉也不会不可接受。


我们过去的实践是 dev 分支必须包含主线所有分支上的所有改动，包括 bugfix 但不包括 release-featureA / release-featureB 这种版本特化的 commit. dev 永远保持线性历史，即它不会接受其它分支的 merge ，只接受 rebase. 这样一来 bugfix 也好，feature commit 也好，都会拍平成对等的 commit ，不会结出 merge 蜘蛛网。feature 分支在并入（ rebase ）到 dev 上之前 reviewer 会要求一定程度的 squash, 保证一个 commit 既不太大没法 diff 也不至于太琐碎 spam 历史线。 然后 master 只作为 tag 使用，打 tag 时往 master 上 merge 一份（ dev->master ）打在 master 上。只要保证 master 上不自行产生 commit ，只接受 dev 的合并，它就永远不需要解决冲突