点不亮进不了 BIOS 说明 CPU 不能工作

CPU 不能工作有几个原因： 主板供电有问题、主板的初始化有问题无法使 CPU 上电、内存无法工作（常见于超频之后）



能点亮一次的话先进 BIOS 把 CPU 电压稍微调高，CPU 和内存频率全都减低一点，并且一次只插一根内存，观察稳定性有否改善，如果有，说明可能是内存条的问题，如果没有，那这台机子也许该淘汰了（主板都换了，还插个旧的 CPU 说不过去吧）

https://stackoverflow.com/questions/50051473/if-constexpr-in-c17-does-not-work-in-a-non-templated-function
https://www.v2ex.com/t/815172#reply10

照上次获得的经验来看，这里应该已经是模板实例化的阶段，所以 GCC 的行为是对的。也许 MSVC 又做了什么非标准流程，无法深究了

@documentzhangx66 我在#28 是让你想清楚「直接操作」怎么操作，操作什么？是指真的去更新 100w 行吗？

@documentzhangx66
你甚至不知道 OP 遇到了个什么问题……

他之前的做法可以 SELECT * ORDER BY pos ，pos 是个浮点，他可以在任意两个 pos 之间找一个数作为新 pos 。但这也许会有问题，所以他想问有没有不用浮点数的方案。

那如果不用浮点的话 没法指定 pos=1 和 pos=2 之间的新数了，想把 pos=100w 移到 1 和 2 中间让它变成 2 ，其它的顺次后移，怎么办？ id=100w 的那行，pos 改成什么？ pos=2 的那行 pos 改成什么？其它的呢？

好，如果不用这种 pos=整数的表示方法，我们用一个链表 ——



回到我的回复开头

我们往表里放了一个链表，现在插入和移动都变得很快了，这很好——

但我怎么知道第四个元素应该是 ID 为几的行？ 看起来 ID=4 被 ID=5 指着，然后 ID=4 自己指着 ID=3…… 那，id=3/4/5 这三行到底是第几个元素？没有映射，他们的 ID 与 next/prev 都不直接反应呈现顺序。当只有一个表的时候这做不到。

所以需要第二个映射表。

第四个元素，按桶大小为 3 估计（我给的例子），应该在第二桶，那么我们
查 SUM(桶容量) WHERE ID <2 ，得到 3 ，
再查 capacity WHERE id=2 ，为 3 ，说明确实在第二个桶里。那么
直接查第一个表 WHERE bucket_id = 2 ，提取出 3 行，看 2 号桶的头，是 id=2 。遍历内存里的三个元素找到 id=2 然后沿着 next 遍历(4-3)-1=0 次，得到 id=2 的元素。
总计 3 次查询完成了随机检索，一次桶表扫描，一次桶表索引，一次数据表索引，内存遍历忽略不计

@documentzhangx66
我是想说无论数据库怎样实现它的索引，在这个业务里并不能用得上。
SQL 并没有移动行然后自动给你更新所有自增列的值这种内建操作。

OP 描述的困境是，用于排序的索引值是稠密无缝的（如果 int 的话）。如果索引是随机访问地址，那么改变顺序就要批量更新大量地址，如果索引是相对地址（即链表），那没有任何现存机制帮助我们随机提取一批相邻索引的行。


数据库自己的数据结构 works perfect so what?
how does it help?

…… 无恶意，你看过 GORM 的源码吗



当执行一个查询的时候，model 一定是「有类型」的，所以在设计查询接口的时候，目标并不是抹除输入数据的类型差异，相反还要要提取出输入的类型特征加以处理。所以 gorm 用 interface{}来接纳任意类型后用了大量反射手段去还原 interface 的具体 <模型或类型> 是啥


之前看过有个大佬写的博客感觉很有启发，泛型能改善的最大问题是高阶函数：

func (S) filter (d []type1, f func (e type1) bool ) []type1
和
func (S) filter (d []type2, f func (e type2) bool ) []type2
是两个不同的函数。但有了泛型，可以只写一次。
https://go.dev/play/p/OHdhzMstFxW

我感觉 拼一套低配 LINQ 还是挺有可能而且有意义的

@documentzhangx66 你再仔细想想，「重排序」的时候你想喂给数据库的是什么？

@xylophone21
@zmxnv123
@documentzhangx66

链表存的话读取会非常慢，不能范围预加载，OFFSET 更是灾难，因为现在没有记录告诉你 第二页第一行对应 ID 是几的结果行，读一页必须找到页头开始的行然后沿着它的 next 遍历到页尾，这件事还不能用 SQL 解决，得在代码里循环，数据库负担就很重了


不过，可以在这个基础上往外加上「桶」来映射排好序的样子可以解决。桶始终保持有序，如果你愿意也可以保持它的 capacity 平均，这样分页 offset 的时候估算会快（准）一些。然后读出的时候只需要检索桶 ID 符合的记录就可以了，与平时基本无异。

当需要分页和 offset 的时候，先提取桶表的 capacity 列来估计，比如一个桶容量是 100 ，我要 OFFSET 到 1000 ，那就先把前 10 个桶的 capacity 全读出来看够不够，当桶容量总体比较平均的时候这个估计是很近似的，要检索的量也很少。然后还是 where bucket_id in []就行

然后桶还可以嵌套，更小粒度的桶可以被大桶索引，而且对更下层的桶来说都无需改动原有的查询流程，迁移负担很小

https://i.imgur.com/Brxd2Z0.png






—— 没错 恭喜我们又重新发明了 B+树

经典正则 vs 括号配对


正则表达式无法匹配成对的括号。 搜索关键词： 泵引理 （ Pumping lemma ）

但其实这么多年手机厂商早已经发现了手机拍照正确的定位

并不是拍出优秀的画面，而是拍出理想的，好看的画面。华为的月亮是「 P 的图」，但并不会影响用户为「一键就能拍出好看的月亮」这件事买单。


手机用户（我指的是喜欢用手机拍照的人群，不是手机生命周期结束后相册里 4 位数都不到的诸位）其实不会关心「成像能力」如何，他会关心的是响应速度有多快，滤镜有多智能，「会不会糊」（降噪、防抖、对焦、分辨率）


对比类产品是很有意义的，但对比的东西怎样呈现出参考价值可不简单

对了， 我有一个（自己捣鼓时觉得很有用）的小窍门：

遇事不决，加入物理！



弹性、引力、摩擦、旋转、软连接。有物理之后的「运动」一下就能不亦乐乎起来

https://store.steampowered.com/app/950180/_/
编程何必真的是编程


对战？
你确定你描述的是 PVP 不是预设关卡下打通关？


只要地图随机，策略就必须每次重写。如果不这么做可以加入主动操作来引入随机性。

用户输入的时候断句分词
https://i.imgur.com/k4Un2ij.png
是不管断开的地方是不是词素中间的


搜狗有很多奇怪但还真比较符合输入习惯的组合，OP 发现的这个「词」也许是分词算法出来的问题结果也可能真有什么特殊词汇。我反而一直觉得搜狗在这方面做得比很多输入法都好所以才一直在用

是，但这个问题跟「 100 日元是不是只能买根葱」一样本身没什么意义

有意义的是「会不会贬值」、「什么情况下会贬值」。但那就是个复杂的问题了。我是不懂，楼下有懂的吗

我用 aria2 ，tmux detach 窗口一关比啥都绿色

。。我只能说

万恶之源 百万亚瑟王

@hhjuteman 我 tm 直接按着编译器的头让它吐个报错来告诉我（恼