zip 的一个硬伤——容易遇到文件名乱码，上面有人提了。
zip （仅指比较规矩的）可能唯一一个比较现实的好处就是现在 Windows 和 mac 等环境都原生支持解压（ Linux 变数太多就算了）。但也不止 zip ，要针对具体系统部署也可以用自解压文件，这也有人提了。（至于点开……我会试试右键菜单。）
因为历史原因，zip 可能有被各种奇形怪状的应用二次开发（像 jar 啊 apk 啊），而有些不太常见的 zip 可能到处都打不开，这也有人提了。别的格式没流行得那么混乱，虽然光看扩展名一样可能有问题（比如 rar4/rar5 ）。

7z 跟 xz 之类其实不是对等的。
7z 是所谓归档的压缩容器格式，可以选择不同压缩算法，比如 LZMA2 基本就是 xz ，而压缩纯文本为主的文档我用 PPMd 压缩率暴打 LZMA （轻松差 10 倍；@Slurp 这问题是我从你这顺便看到的，但本来没打算找你茬，但是真有这种重量级负载好歹多了解一下怎么选型吧）。
当然文件扩展名看不出算法有时是劣势，但同样影响压缩格式和效果的其它参数就更不用指望看到了。
相比之下，gz/bz/xz 等是通常以文件流为单位的压缩格式，tar 是无压缩归档格式，两者并用才是 7z 和 zip 的类似物（除了存储 /无压缩的归档功能基本就是 tar——不过 tar 确保兼容 UNIX 权限）。

可移植性基本都不成问题，主流系统上都能用，而 7z 基本是这里面除了 zip 以外最流行的。除了专用格式的工具，我是记不起不支持解压 7z 的非古董压缩软件。
UI 问题也不大，命令行大差不差，GUI 嫌弃官方老土或者根本没有，就换个 PeaZip 之类的。
嫌弃 tar.gz 太啰嗦改 tgz 体感也没差多少，当然 7z 默认比较省事。所以我自己的东西默认发二进制包就 7z 。

@Slurp 虽然我原认为你不配享受到原文挨个儿 biu 的程度而只是需要对妖言惑众做 viewpoint coverage 来回复，不过看你历史回复，我改变了主意，觉得浪费点铜币把剩下漏网的全部补完，就算当科普笑话给路人看也行。
（也就是你原来扯蛋的密度够高了所以扣除引文不用补充多少，以下不再重复。）

> 不知道其他语言 IDE 的平均水平。

你该知道，大部分语言都没专用 IDE ，通用 IDE 基本就是文本编辑器+构建工具，IDE 多出来的检查约等于无，平均一下也无了。

> 说白了就一句话，「说得对就应该改」。

一句废话。

> 不知道扯那么多干啥？

欠教育和教育的表现对应是连贯的。就像引用你全文一个个揪出槽点比单独挑重点科普解释更顺气，阅读体验也可能更好——除了可能更长，不好意思。

> 抱着一副「你 IDE 就是垃圾」的嘴脸，却连提示你 http not secure 这种都要喷几句。

HTTP 这个例子解释一下，开始是昨天某群里看见的对字符串字面量爆出的笑话。
我本来以为一个没决定用途的字符串字面量该用什么是用户的决定，IDE 在此的自作聪明是显而易见的——比如说，用户就是想拿 "http://example.com" 去做一个“这是一个 HTTP 样例 UI ，大家得知道 HTTP 虽然不太 secure 但很不巧这玩意儿当链接真的能点得开”的 UI 上的例子。
没想到你甚至理解不了这茬，我的错咯？不过这样你就更没资格计较我为了兼容你的理解能力而拖长回复（又没问你要铜币）了。

> 你不是天天标准标准，怎么一到 0 warning 0 error 0 typo 这种要求就知道是工作不饱和了？就知道有限资源了？

我日常工作天天都有 spec ，倒未必费有打白工到标准上。
你所谓的这种要求恰好就是代码验收方面 spec 不成熟而集中暴露开发出资源矛盾的典型表现之一。

> 有的人就是喜欢 -Wall -Werror 然后一条一条把假阳性标称白名单。轮得到你指责吗？

我是用户我就有可能轮得到。

> 叶公好标准，不过如此……

还能多挂挂语文水准的问题。
历史上叶公是谁，评论叶公的又是谁，这梗语出何人？你是真好意思代入了嘛？

喜欢追着别人的回复评论列表咬，算是让我见识到了。
你也不用杜撰“有的人”了，直接 at 不会 at 。别说你不懂怎么 at 。

「不浪费铜币」我说过，咋地？你财大气粗无所谓那是你的事。
但这排不上主要原因。要是眼睛不好使到看不到格式的优劣，那就别提什么“符合 V2EX 风格”了，听着像揭 V2EX 的短。

这里不少就是两者都用过以后的常识，不过按“请尽量让自己的回复能够对别人有帮助”的宗旨，就直接展开了（才不是懒得把这坨贴成 gist 呢……）：

v2 有比 gist 多（大约自动的）内容审查。
gist 直接写 md 带格式。
gist 可以多版本，能查看历史记录。
gist 不会自作主张插入空格。
gist 可以多文件。
因为自身的设计逻辑，v2 按回复内容长度而非内容区别对待回复者，但 v2 的主要内容并不都像微博那样统一限制字数就可保证阅读体验通常更好。有的内容自然更适合展开再看。
……

@Slurp 字多和有逻辑的关系是你自己瞎脑补，别瞎栽赃。

字多咋地，看到字多你写不顺所以 PTSD 了？你有意见又咬不到人，所以就一副满世界“我受伤啦死给你看”追着别人的回复列表在无关的主题里跳（还有一些地方带着个可疑的“❤️ 1”），一副苦大仇深的，有意思么？再说，我字多了，岂不更言多必失给你更大的攻击平面，你却连窃喜都不会，是不是语文水平有问题啊？

同样的字数多发几篇回复澄清你这些问题还更占地方，我还觉你不配呢。

@Slurp 有的人就只知道 exact match ，不知道 subtyping polymorphism ，不知道拿 C++举例是为了兼容下限。

C++欠抽在哪用过点都知道，不必多科普，但是从你这发言看，逼迫用户带着脑子避免依赖 IDE 这种品质极不稳定玩意儿，而不是让习惯像你看齐给人拱火添乱，确有进步意义，也是很必要的。

你以为现实的没有能力决定选型方向的用户，有多大本事选择工作时用的 IDE ？又有多大本事钦定几个 error 几个 warning 几个 typo 以上算验收不合格？就不说还有故意引入这种“问题”的了（反而不一定表示质量有问题）。

另一方面，脱离 IDE 就直接干不了活（而不仅仅是效率问题）的用户是不是配来妖言惑众，至少在 v2 还是大大地该打个问号的。就算是实际工程中普遍最依赖的 IDE 的 Java 之流，一开始教语言基础时也没说非得上 IDE （当年就很多上 EditPlus 的，不知现在流行啥）。这这样数典忘祖可不好。

你 IDE 作为软件产品不一定就是垃圾，但是 IDE 对代码的检查比起编译器普遍差不多就该当做垃圾，至少编译器对误报可没法那么放水。想要推翻技术常识？行啊，造个取代编译器的 IDE 来成为业界主流？

0 warning 0 error 0 typo 是轮得到你提的么？我从没听说过你这号人物，但就你这儿的发言看，是对你脑子是否比既有 IDE 的设计靠谱，什么东西配当 warning 是否拎得清楚的能力是要打个问号的。反过来，标准起码能定义什么叫 ill-formed ，成为 error 的直接依据。要还有不服，那你给个备胎？是你技术和脸皮高超，有底气确保把你敢用的 IDE 的设计文档都偷过来公开，然后担保更好用么？不说有限不有限，你有这资源么？

有的人就是喜欢 -Wall -Werror ，那只能活该你遇到有的人给你添堵咯。还有你搞错了个常识，用 -Wno 和 #pragma 加白名单排除诊断多数就是反对具体的诊断的目的，大多并非假阳性（检查过于严格地不准确）。另一方面，你对工作量毫无认知。你倒是看看有多少用户没事把 IDE 检查全开然后还有心情去白名单，而不是直接关掉？或者说你是直球侮辱 IDE 提供实现了的检查的数量很弱鸡么？

你一没搞清楚前因，二不清楚你评论的内容，三没搞清你脑补的观念在实践中的影响，就这一问三不知还好评价别人好什么？这脸皮倒够好为人师了。

@zjp javac 检查弱后果的下限上没 C/C++那么严重，因为很少有别的语言在语义上有那么多不要求错误（有的还不能是错误）但很坑的东西。少部分特性，如 @Deprecated ，Java 还属实更先进（了那么几年）。

Java 真正坑的地方是一贯鼓励写啰嗦代码（虽然啰嗦不绝对是坏事，但大部分情况是），以至于 IDE 和纯文本编辑器的体验差距被毫无卵用地拉大了（用 IDE 会少吃亏，不用 IDE 会多吃亏，但横竖都是吃亏）。这种讲究生产力提升靠熟练专用工具来掩盖抽象软弱的思路属实反智。

@zjp 实际上 VS 和 JB 之类比较成熟的 IDE 当然都支持配置诊断提示，但这里真正的问题是，不管实现质量问题，开发者有必要认识到，这种 IDE 提供的诊断先天就是低人一等的。
而分配资源优先级解决不同的问题是工程人员的基本素质。

这里，最上等的诊断消息是语言实现给出的错误和警告，无视这些问题原则上（不排除编译器和语言自身 bug 之类的极端情形的例外）会导致得到的程序根本就不是想要的东西，不中断构建基本就是写 bug 浪费时间（编译错误的话编译器自己就终止了）。这种诊断当然是最优先考虑的（要想无视编译错误就别编译了）。
次一等的是 lint 类工具，历史上就是为了缩减编译器实现的难度和编译性能开销而从编译器分离出去的次要的诊断，这是来自语言设计者的判断。现代语言实现的性能宽松得多，如果检查发现的问题足够重要到对语义有普遍影响，把 lint 的分析加回编译器变成警告也是很正常的。如果仍然保留在 lint ，在一定程度上说明这本来就没那么重要，这个区别一直是 by design 。（当然，对一些都未必有编译器的动态语言来说，核心语言实现和 lint 诊断的差距可能相对不那么大。）
而 IDE 自己提供的补充诊断，是重要程度相对最低的。并且，假阴性（漏报）完全没有 spec 参照而无上限，假阳性（误报）的情形也极度宽松。还有很多时候和代码风格约定强相关。追溯这些诊断来源的性价比远远不如上面的，以至于把这些和上面的来源相提并论差不多就是碰瓷。

次要的问题是，因为 IDE 的实现标准比较宽松，所以就算是最有必要给出诊断的提示（甚至就是编译器警告），比单独运行的编译器之类核心工具的分析准确性普遍差很多，特别是 C++这样分析难度离谱的语言。像 VS 用的 EDG frontend 那个红线经常是只能整个关掉的程度，眼不见为净（主要是复杂性离谱，而不一定是实现水平烂，EDG 曾经是唯一实现过 C++03 export 的厂商）。即便没红线 IntelliSense 崩溃至今仍然是家常便饭，我天天遇到。其它 IDE 用 clangd 之类能基本解决比编译器死得离谱的问题，但是想万无一失还差得远了（这年头没遇到过常见编译器 ICE 的都不太好自认为熟练用户了……）。

再者，光是编译器能给出的问题其实已经非常多了。像 VC++的 cl 默认开全警告会因为假阳性（指用户有意的，不算 bug ）太多烦死，所以正常警告都不可能调最高（已经排除了就是 note 的部分）。（ g++这种诊断没编号的反而策略现实很多，加几个选项会警告的基本全是需要改的问题。）这样的问题，正常开发者（包括写编译器的）都不可能完全摸得清楚，基本是遇到坑了去长记性。本来已经够不太平了，还要照顾 IDE 的一堆莫须有问题是不是工作量不饱和？

其它语言经常没那么极端所以 IDE 体验较好，但没什么 IDE 厂商保证这里不存在差距，踩坑了就是自讨没趣了。

所以实际情况是，不分析很具体的问题，笼统相信 IDE 并多启用功能是很外行和幼稚的想法。作为专业人员，不要试图和有限的资源过不去，这类想法一开始就不要有。

@AA5DE3F034ACCB9E 我不知道你哪来的感想。
我“这番”言论，是哪几番？不说情绪输出，光是逻辑推理和类比的例子就好几段，我是真奇怪你是怎么做到刻意无视回复的主要内容并从中得出“没有依据”的结论的？

我针对的就是小白有原罪（以至于“氛围”就算真有问题不值得先摆上台面上说），但我都没说 OP 这问题纯小白，反而在上面指出了有对 OP 问题吐槽的回复的问题。
注意这里说的并不是通常意义上小白仅仅因为无知偶然地浪费他人资源而有罪，而是指小白在不受到限制的情况下会因为自然繁衍而占据多数，劣币驱除良币，窃据消费者的代表，和非小白的利益更直接地对立，资源有限时就可能发展为敌我矛盾。
（这背后和苹果的放任有重要关系，但还是没怎么展开。）
这种时候是赶尽杀绝还是分化统战是个问题，但单纯 block 肯定是没建设性的。

这问题跟你理解的虚拟机概念无关。不管你有没有理解错 Android 虚拟机实际怎么跑的，都没法避免卡。

——关键理由是，因为是连你看得见的 UI ，包括负责整个系统交互的主要逻辑，也在虚拟机里跑了。而且，这些关键逻辑难以和你卡的 app 隔离——即便是在不同实例，也需要共享输入输出的硬件而同步——对普通用户来讲，它们正常情况下就是被独占的（ Android 默认也不像桌面系统一样有放弃会话切换用户的 UI ）。

在这个前提下，硬件调度之类都是实现细节。

不跑在虚拟机里的更底层的宿主可以不卡，但是你感觉不出区别。

@kop1989smurf

> 至于说“intel”

原问题好不好另说，你这条就是烂思路。

首先 OP 就问了 Intel 咋地，你觉得“不好”，所以不准？

其次苹果又不是外星厂商，它生产产品是要给蓝星全体产业付出代价的，比如 IC 设计就可能挖得到 Intel 的人。还是你真以为苹果天顶星科技可以无视上游供应链了？
Intel 也不只是 Intel ，AMD 之类的友商也是这么干的，说白了 Intel 是指代非苹果的所有传统势力。把这问题的 Intel 换成 AMD 也通（真有区别就是 Intel 抄大小核之类更积极的先例摆在那）。而这里的路线冲突恰恰是关键问题之一。
你要就苹果论苹果，反而更没价值——单苹果自己圈地自萌真没那么多人有兴趣关心。

如果非得强行无视供应链的决定性作用，那么换个一个角度：消费者的做的事。
苹果焊死这些配置意味着消费者不能自己定制相关部件，相对现有主流方案就是净损失。
你可以说有的用户不关心，但是对关心这个问题的用户，想要下克上劣化主流产品可用性，那就是找怼。

类似限制消费者定制的思路不只是硬件配置。因为历史原因，苹果成功窃据了“智能机”领域作为自家后花园把用户当孙子养，说侧载坏，然后一坨苹果用户就跟着多数票暴政起哄。
然后看看苹果敢在 mac 上吹不？
也就是 PC 市场主流用户不吃这一套罢了。

这些倒行逆施暴露了苹果其实也就是捡软柿子捏罢了。
而不管是不是占主流，有定制需求的消费者怼苹果，基于屁股的逻辑上不会有什么问题——就是抵制残废消费品的垄断，捍卫自己的选择的权利。

一个衍生结论是，这些产品如果作为生产力工具那么会更加不得人心。更普遍的一个例子：闭源的软件就比开放源码的更残，而容易失去市场竞争力，尤其是开发者接近的那些产品。
任何想对市场地位和历史影响而不是区区现金流有点追求的厂商都该长点顺应历史行程的记性。

@AA5DE3F034ACCB9E 那就得趁早教小白做人，免得小白多了反过来就被教做人了。

自有 PC 以来，可定制就是标配。消费者不能定制的产品，是出自 OEM 节约成本自己定制阉割的低端型号，比如笔记本低端显卡焊死高端才能自己换。

不提醒一下苹果这种低端特供商的用户，某些消费者还真拿自己当回事了。

完 善？

一看就知道 OP 没体验过 VS 的红线有多蠢。
再讲个笑话，CLion：HTTP 链接不安全。
编译器就算了，你个 IDE 也配定义啥叫 Error 啥叫 Warning ？

没能力区分诊断消息来源和区别分析原因的开发者，拎不清程序语义和业务目的要求的含义的，review 时直接盯着重点伺候。

@Mark24 那就不算产品，不用指望什么独立性。

反正用户都判断不了哪个是哪个。

所有软件都一样。

以产品的角度讲，独立编程语言的标志是有明确能帮助和其它友商竞品划清界限的产品规格说明书，也就是 spec 。
当然，现在这方面普遍比较水，所以经常有 spec 在搞了在搞了然后实际得 reference 凑数的情况。（讲个笑话，Rust 。）
只给实现的语言，也就是能算是语言，作者说是几个就是几个，你干嘛还要替作者操心究竟是半个、一个还是一个半呢？

@Mark24 你对得起你的头像么。

@stephenyin 有没有一种可能，最有能力的那些同行本来就能在一个比较大的范围内选择想在哪就在哪发展并保持相近的生活水准，就算多赚的那些钱也买不到这种余裕，而选择在最卷的这种城市里才有不错过赚钱的安全感，只是实力不够或者怂了？
如果是这样，这边评价对错改变不了任何事所以没多少意义，对方说了可能才做数，即便对方经济实力远远不能相提并论。

@registerrr 道理是这样，但现实是进去可能得隔离封控，而且意外延长的概率嘛……
在有先例可循的情况下可没多大幻想的空间。于是要么存心就当自己是土著，要么能不去就不去，骑墙派是越来越少了。

提醒 OP：在城市建设没明确领先，资源获取又差的局面下，一不小心，和个别城市绑定过深（包括户口）而没有退路
乃至暴露出这个想法，都是可能变成整体失分的负资产的。（唯一的例外是在别处没有同类同级别机构的机要部门工作，因为工作性质人走不开，但这个单项同样得损失生活质量而会扣分。）现在还在过渡调整，就看主流市场啥时候反应过来这点已经攻守易位了。

@yanqiyu 学 C++ 到能干活这事本身就是一个比单纯看文档高得多的技术壁垒，一开始就直接用最权威文献避免在各种二手来源之间脑补翻译掉坑还明显更省时间。
越来越多的改动现在其它材料都跟不上了，如果始终适应不了找对东西看，那么看不懂日常代码也是迟早的事。

@Nugine0 我不清楚你具体在关心什么问题。我说的“默认”“大多数”“计较成本”即便无法明确绝对边界，全部是客观现实，你也没提出明确异议和理由，只是说有不同情况，然后要我评论不同替代方案。那我也说了，其它情况就适合去用 union type ，而不是半吊子。
要再明确一点，就是现实没什么中间路线值得添加新的设计，被迫接受是因为（多数）用户摆脱不掉语言的既有设计只有这类不靠谱的选择这种状况。但吃哑巴亏吃惯了也别斯德哥尔摩综合症了，该干什么是在用语言实现之前就能弄明白的。

我的长篇大论都有专项备份，本来就都是草稿。

@kerrspace 大量的，比如 std 里的容器实现那种算不？

不明确目的那可能不是你不懂怎么看代码的问题，而是设计文档不够，你撞上得对着源码逆向设计的坑了。再清楚怎么看源码的技巧也不保证能猜对目的，除非你自己刚好写过类似的。
要是这个问题，找 PM 帮忙，否则就凉拌了。

看书你速成不进。
正经学 C++的我都是建议自己查 eel.is/c++draft 。不习惯索引就 cppreference 凑数。

但是所谓专攻什么类的就别指望了。虽然类占了几个 Clause ，但说白了也就是一种类型构造，在整个体系中不配占多少篇幅。近 20 年内会拿这个当重点讲的材料基本都可以直接当作是质量比较差的。

还有别自己骗自己。类都拎不清楚，模板呢？你写数据结构没用过？

虽说正经意义上这里有没有说得清楚的语法(syntax)都是个问题。

@taotian 除了 unsigned char 之类的缩写还能算是偷点懒，大概是其它语言用多了的典型自作多情。

像 Win32 SDK 里一坨 typedef void VOID; 一样一股早年 BASIC/PASCAL 糊傻了的瘆人味儿。还有 BOOL 这种笑话……当然这里的 #define 就更加神来一笔了。

表面上看是统一代码风格，实际上就是进一步用非标准方言分裂用户习惯。又去不掉原来被 typedef 掉的关键字，用户用了还能拒绝编译过？结果就是更加混乱。

正常点的做法就是 POSIX 这种，扩展现有语言标准，那么就不要重复已有的废话。当然这样有个后遗症就是不可能指望统一什么鸟 PascalCase ，但就算不这样也本来不能指望（没几个环境能彻底干掉小写的关键字）——作为 C （ C 艹同理）用户必须熟练见人说人话见鬼说鬼话，能做到通过标识符风格区分来源。

唯一一个例外是语言标准明确钦定特殊地位的保留标识符，不过这个就不是打算给你用户使用的。不过 C23 也干掉 _ 开头的东西了。（讲个笑话，bool 终于要是关键字了……）

@duke807 符合 ISO C 的 char 必然是 1 字节。C 允许 1 字节不小于 8 位。

@424778940 不存在 8 位的 unsigned integer type ，就不要求提供 uint8_t 。反正有 uint8_least_t 。