非专业卡驱动有限制每个系统（不是每张卡）能开的 encode sessions 数量不多于 3 个（如果驱动版本不太对甚至只有 2 个），虽然据说能 hack 驱动绕开这个限制但换我是开发者我也懒得整这种吃力不讨好的事。
另外理论上如果一个视频编码很整蛊的话（每一帧都要参考上一帧）是没法分段的……

点开之前就知道里面啥样，不过希望这里坚持____的__fans 们，不要在提到张小龙的时候瞬间变脸

别知道个 lazy xxx 就开始乱套了……又不是 100 年前浑沌未决的时代，今天但凡线性代数及格了（及格，指学过基本常识，不是指在某张声称是线性代数的卷子上得到超过 60%的分数）都不至于对这么一个破有效理论大惊小怪。至于连有限维会带来什么影响都搞不清楚抱着这么个有效理论指望得到啥深刻东西的……算了算了我们还是聊宗教话题吧。

至于宗教问题，我们野猪教的建议是：「轮回」不应该被解释成死后怎么样，它更接近于讨论「现在的我」和「上一刻的我」之间的关系。

@7zlid #7 出门左转 Bell 不等式……

这楼看着有点麻……

先说加法和乘法。这俩玩意跟运算规律一点关系都没有，或者说起码也是个本末倒置。加法（或者说 coproduct ）和乘法本质上是特殊的(co)limit ，而(co)limit 总是与其他的(co)limit/adjunction/...在特定条件下交换，这才成了最终被观察到的「运算规律」。特别地，标量和向量间的「乘法」最终归结于 monoidal category 里的那个"tensor product"，它不是传统意义上的 product ，满足的公理也是五角大楼……不对串味了……是五边形图表交换，而不是传统的(co)product 。「正确」的直觉乃是激发态与 domain wall 的融合：想象有堵墙，它就是向量，然后你往上面砸一种很均匀的屎，这就是标量和向量之间的「乘法」（以下省略乘法边上的「」），如果墙是虚空墙，那你把一坨屎挪到这个空气位置上假装这是个屎墙，然后往上继续砸，手感和你砸墙也没啥区别，这就是为啥有时候看起来标量乘法和它与向量的乘法有点像的原因（以上都可以严格证明，但在此省略一千页辅助材料）
绝大多数人看到的「抽象」代数，无非是魔法的余烬（ co-ash ）罢了

======分割线：所以 if err != nil 爱好们明白为什么和类型叫和类型，积类型叫积类型了嘛？明白之后就可以开始学习什么是 monad 啦======

所谓 v 和 w 的 cross product ，是这么个过程：
在可定向的伪黎曼几何上有切丛与余切丛间的 musical isomorphism （所谓的升降指标）最终使得
v,w 经过 musical isomorphism 从 1-vector 变成 1-form
n-form 和 m-form 间总有 wedge product ，结果是一个(n+m)-form （所以现在我们有了一个 2-form
这个 wedge product 经过 Hodge star 变回(d-2)-form ，刚好 d=3 ，所以它是 1-form
这个 1-form 经过 musical isomorphism 变回了 1-vector
这就是所谓的 corss product ，而最开始的定向（所谓的左右手）就是最后结果「人为」的地方，而不难发现，这里面最「刻意」的地方，在于一切只刚好对三维空间成立

有人喷了 10 年命令长都不愿意花 3 秒（其中 67.8%的时间用于启动 PowerShell ）输入一次 ls 试试（与此同时跟它说 git 设计得蠢就嘲笑你连 alias 都不会设置）
有人喷了 10 年 Windows 文件名不区分大小写，却坚信 PowerShell 命令是大小写敏感的
所以你觉得这玩意用的人少跟技术有 1%的关系？

@ffire #93 我在那一层不是说了么，inline 那么用 100%是对语言关键字理解有错，没有什么争议。剩下的都是 OP 实际上在写 C with class 而不是 C++的标志，不是说绝对不能用，但这种东西满天飞的代码基本上只用了 1%的 C++特性，这上面 vim 能用是绝对证明不了在其他 C++特性用的多的项目上 vim 能用的。这就像是…如果一个 TypeScript 的环境只对一堆 anyscript 代码测试过，能证明这玩意「能用」吗？
另外这整个楼和我说的这些相关的历史是这样的，最开始有个人说类型推导等东西 vim 估计干不了，然后这个时候 OP 如果直接承认自己平时就不用 auto 等涉及类型推导的东西所以不知道能不能用，那我绝对一个字都懒得打，毕竟不用什么或者不知道什么都很正常。结果 OP 在主楼贴了个 int x =1; auto y = x;来「证明」 vim 下面能正常看到 auto 类型推导的结果……这就相当于有人说 C++编译慢，然后一个人写了个只有一行 int main() {}的 cpp_is_so_fast.cpp 一瞬间就编译完了然后说 C++编译一点都不慢啊，这你让我说什么好？
到这个时候我第一次回复还是只关心 vim 能不能用的，结果 OP 不知道吃错了什么非跟我扯 shared_ptr 觉得我 C++水平有问题，那我只能翻翻他都写了什么神奇代码了，到这个时候我列出来的那些（中的一部分）才成了「问题」，因为我真的看了他写的代码发现并不属于应该用这些特性的情况。所以归根结底，我根本就不关心别人用什么 IDE ，但 OP 非要用这种方式「证明」 vim 上能解决一个自己平时从来不用的特性，然后接着又出来秀自己 C++水平的下限觉得别人菜，这总不能怪我吧？


@liuxu #106 我也觉得有这时间不如开一盘 dota ，所以有什么推荐的新版本整蛊姿势可以让我去坑害队友吗？

@ffire #83 你就没看懂我那层楼在说啥……这个主题不是关于 vim 的么？我说的是 vim 这玩意面对复杂的 C++项目是不够用的，这些东西的集体出现说明项目本身没涉及到 C++里面折磨 IDE 的东西，vim 能在这种项目上用是因为项目简单而不是 vim 强大。我虽然看 C 很不顺眼，但如果这个主题里面的截图都是拿 C 演示的我一句话都不会多说的，毕竟我不怀疑能拿 vim 来写一个 C 项目。

文字版： https://telegra.ph/%E6%88%91%E5%BA%94%E8%AF%A5%E5%8E%BB%E6%89%93%E7%9B%98dota%E8%80%8C%E4%B8%8D%E6%98%AF%E6%89%93%E8%BF%99%E4%BA%9B%E5%AD%97-08-27

图片版：
https://i.imgur.com/UTOq8LC.png

太经典了：写个个位数行数的 C with class 证明 vim 也能写 C++，然后把这种 C with class 代码堆上一万行证明 vim 也能写非微型 C++项目。你问我咋知道是 C with class 的……随便看看这几个图里面有啥：在一个非历史遗留项目里面能看见 stdio.h, main(void), wcslen, 传参往进传 const wchar_t*，星号贴着变量名写，裸指针满天飞 ownership 一团糟，auto 仅用于演示自己宁可偷偷把 size_t 隐式 cast 成 int ，NULL ，以为 inline 是建议编译器内联……除了最后那个跟[Google C++ Style Guide]( https://google.github.io/styleguide/cppguide.html#Inline_Functions)同一水平的离谱错误，剩下的当然语法和语义上都是“正（能）确（跑）”的，但这么写的 C++是啥样懂得都懂，我就不逐行品鉴了

C++这种折磨 IDE 的东西，只要用点复杂的 template 很容易就能把 Clion 的类型推导提示给炸了，这种时候 LSP 什么表现我都不敢想（所以那帮让人用 vscode 写的已经很恐怖了），至于连 LSP 都不一定有的……算了算了不说了

让鱼摸你

以前试用过，最后的结果是在又一次出 bug 之后大彻大悟直接转 Powershell 。
所谓现代化就是干点人事：放弃了啥玩意都当字符串传然后收到之后再去 parse 这种纯整蛊的设计，把类型系统弄得像点人样，把某个对象是什么和它会怎么被显示出来这两件事分开。比如 ls 结果是一个 table 可以直接用 index 取里面的东西，而不是得到一大坨字符串再解析第几行第几列。然后很遗憾，一旦接受了这一点就已经「背叛」旧世界了，命令的皮长不长得像 bash 其实并不重要，你看 Poweshell 里面也定义了一坨同一个画风的 alias ，还不是无数人整天复读敲 Get-ChildItem 费手所以它是个垃圾……这就跟 Rust/C++无论做成什么样都不可能替代 C 一样，跟技术一点关系都没有，你跟那帮 2022 年还觉得 C 是《高级汇编》《贴近底层》的🐗怎么交流嘛。
在这个意义上怎么看 nushell 和它那帮拿 Rust 糊的「现代」命令行工具兄弟们（特指那帮作为 modern xxx 而生的，反过来如果单纯想糊个好用的东西那自然是什么事情都没有）怎么有点尴尬：往前看讲究一个《封建忠诚》，光看你这层皮就知道不属于人家《牢不可破的联盟》；往后看的话这几个货相互之间一点配合都没有（也没办法，大家都喜欢源码分发，Rust 一时半会儿也没个稳定的 ABI ），纯靠 nushell 维护者手工往里面塞东西也不是个事，能像.Net 之于 Powershell 一样的东西连个影子都没有，那天花板也就那样了

在不在堆上其实不是个问题……总的来说建议不要用“多维数组”，然后把它分成「一坨数据」和「访问方式」两部分，这样不管是写起来还是用起来还是做优化都比较方便（就像 graphics API 里面总是把 texture 和 view 分开一样）。
举个只用标准库的朴素例子：
https://i.imgur.com/Kc3zbIb.png
（没有 C++23 自己去毛一个 https://github.com/kokkos/mdspan

既然 bash 这么好用，希望你以后写别的语言的时候主动禁用除字符串以外的所有非函数类型，所有的函数类型都是 string->string ，永远只传一个字符串进去然后用自己绝世的字符串处理技巧手动解析出需要的信息，最后再把需要返回的信息编码成一个新字符串返回

另外这种能觉得 bash 是个好东西的审美……真的强烈推荐尝试一下 C 和 Go ，你一定会喜欢的！
（无奖竞猜：这三个的共同点是____

要么收购索尼互动娱乐，试试搞一把《神仏習合》；
要么就干脆别搞，这样永远可以对着分不清 CPU 和 GPU 的高质量用户群体宣传游戏生态不行是开发商不配合，让它们在对这么好的芯片被浪费掉的惋惜中幸福地度过一年又一年

感觉可以自己糊一个东西来存 tag （或者其他的 metadata ），想干什么就干什么，然后扫 NTFS 那个 USN 日志来维护文件本身的变动就完事了。既然有 everything ，很难想象没人糊过类似的东西。

话说文件 tag 有啥很爽的用法么，我用 Mac 的时候就没咋搞明白这东西怎么玩合适，以至于现在一点自己糊一个的动力都没有。。。

扫了一眼字节那位的文章真的说不出话来……

「所谓硬解，即指使用 GPU 内专用于解码的芯片来处理解码工作，由于 GPU 多核心低频且专一的优势，在解码视频时发热和功耗显著低于 CPU 。」
敢情调了半天包，愣是没整明白视频解码用的就不是通常的 GPU 核心，Apple 那套 GPU 性能宣传法骗骗外行也就算了，这亲自实现了代码都没搞懂到底是真傻还是装傻……

「考虑到 Apple 其最新 Apple Silicon 芯片专门实现了支持 H.264 、HEVC 和 ProRes 的专用编解码媒体处理引擎，看在 Apple 这么努力的份上，我首先挑选了 macOS 平台来进行尝试 。」
我寻思 GTX960 那一代就支持 HEVC 了，Apple 到底努力在哪了？

「遂观察其实现逻辑，发现 Windows 的硬解实现逻辑与 macOS 完全不同」
想来想去没想通这编解码个视频到底和操作系统有啥关系……整天跟 DirectX 过不去干嘛，就算 Vulkan 的视频相关扩展用不了不能一次性解决两个系统三家硬件（这玩意好像挺新的我也没试过不知道有啥坑），但反正硬件一共就三家，照着 SDK 里面的 sample 和文档抄一抄做三遍也完事了，照现在你这个搞法咋支持 Linux……哦不支持啊那没事了，虽然跟我没关系，但感觉 Linux 用户真是倒了大霉了，就因为实现者脑袋不咋转就莫名其妙失去了支持 (//●⁰౪⁰●)//

文字版 https://telegra.ph/%E6%B2%A1%E6%9C%89%E9%87%8E%E7%8C%AA-08-02

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