因为程序可以选择查看自己的标准流是哪里并选择不同的行为。比如 git diff 在 stdout 接入 terminal 的时候默认使用转义序列显示彩色，但 stdout 接入文件时默认不用。

> 说敏感吧，毕竟有 sha256+secret key 加密。 说不敏感吧，如果换成别的 userId ，就可以查询其他用户的信息。

我不知道从何吐槽起了。

曲线不存在“天然的凸性”（至少不是你所期待的那种意思），因为需要一个观察方向，哪个词对应哪个函数其实是任意选择的，重要的是“凸集”的定义。

通常的用法中，凸函数是指上境图是凸集的函数，凹函数是指下境图是凸集的函数。

另外，凹和凸这两个字的内侧都不是凸集。

你试过重启 uTools 了吗？（我不知道 uTools 是什么。）若重启 uTools 后正常，则说明之前更新 PATH 之后 uTools 已经在运行的进程没有使用新版本的 PATH 。如果仍然不正常，说明 uTools 会指定它启动的进程的 PATH ，于是你需要研究怎么设置 uTools 。

另外从提示消息来看 uTools 打开 VSCode 后你使用的是 PowerShell ，那么你可以通过 $env:PATH.Split(';') 查看 PowerShell 进程的 PATH 。

@LotusChuan #7 read/written 是早期技术 /设计问题 https://devblogs.microsoft.com/oldnewthing/20140403-00/?p=1333

out of memory 的典型翻译是内存不足，而不是内存溢出，“溢出”几乎都来自于 overflow 。

>耗无语感

对输入法是如何学会这个词的表示震惊。

你期待 ((List<object>)new List<Apple>()).Add(new Orange()) 发生什么？

关于 foreach 为什么可以，很可惜，这是 .NET 1.0 的罪孽，因为那个时候没有泛型，如果 in 后面的集合必须采用 IEnumerable 的话，将只能枚举 object 。实际上 foreach 会强行转换得到的对象，见 https://ericlippert.com/2013/07/22/why-does-a-foreach-loop-silently-insert-an-explicit-conversion/

@723X #24 你可以意识到 remote app 的快捷方式就是启动脚本吧

用户 != 人。

我的电脑只有我一个人用，但我日常会使用普通用户，管理员用户仅在需要的时候使用。有的时候我也会把软件安装到专门的用户里面以隔离之，见 /t/638439 。

如果只有一个用户，明显的区别在于新用户是否自动有这个软件，如 #1 所述。

不明显的区别在于它是否“污染”整个系统——如果以普通用户的身份运行，那么这个软件在默认的安全设置情况下是无法污染整个系统的。

设计不好的软件可能在更新的时候需要重新获得原来安装时的权限，这样的话普通用户会无法更新为所有用户安装的软件（ Office 无此问题）。

我个人推荐为当前用户安装，这样出问题的时候可以优先选择重建用户资料而不是重装系统。

只要你没有真的点同意，那就是没有同意，技术实现不等于法律实质。

如果那个邮箱没有人注册过，可以去注册，再重发邮件，我之前有过这种情况。

还可以和客服联系要求撤销礼品卡并退款，解释清楚你是输入错误就好了。如果 Apple 不同意的话你可以尝试让你的信用卡发行商收回付款，理由就是“没收到货物”。

以后给自己买礼品卡的时候复制粘贴自己的地址就不容易出错了。

@Keen06 #101 问题在于“完事”（以及行文中暗示的编译器不会真的反复修改虚表指针）而不是在于“直接 resolve”，当然可以把构造、析构函数里直接在 this 上调用的虚函数绑定到当前类的版本，但是这样做并不总是可以省去修改虚表指针，否则很难处理通过 this 的副本（包括调用其他成员函数时的 this ）调用的情况。

@mind3x #72

> 当然实际上 C++编译器不会这么没效率，就把构造函数里调用的函数当作非虚函数在编译期直接 resolve 完事。

很多时候不能这样做，因为构造函数、析构函数可以调用其他成员函数或者把 this 传入其他地方，在其他成员函数里或者通过复制的 this 调用虚函数必须仍然得到正在被构造的类的版本，而且对 this 所指向的对象用 typeid 也必须得到正在被构造的类。安全的做法是反复改变虚函数表指针。

因为不同的国家可以自己制定规则，它们有不同的想法。有的时候可以和语言相关，比如魁北克采用 gouv.qc.ca ，因为法语里这个词是 GOUVernement ，拼成 go 会导致错误发音（哥窝切），而 gouv 是正确发音（孤-v ）。

设计不同而已。

Java：对象在任何时刻的类型都是最终类，无论何时，调用虚方法的效果都是最终重写。

C++：对象在构造、析构期间的类型是当前类，可能不是最终类，此时直接或者间接调用虚函数会得到当前类的重写。此时也不可通过 this 访问兄弟类，即使整个对象的兄弟类子对象的构造函数已经运行。

C++ 的设计理念基于非祖先类子对象状态的不确定性。

你可以认为 C++ 里面祖先类的构造函数在子类构造函数之外，而 Java 里面祖先类的构造函数在子类的构造函数之内，且处于开头。

也就是说，考虑 A : B 以及 B::B() { B_ctor_body; } A::A() { A_ctor_body; } 以及 new A()，则

Java 认为发生的事情是

{
/* vtable = A_vtable */
{ B_ctor_body; } // B::B
A_ctor_body;
} // A::A

而 C++ 认为发生的事情是

{ /* vtable = B_vtable */ B_ctor_body; } // B::B
{ /* vtable = A_vtable */ A_ctor_body; } // A::A

@sarvatathagata #97 应该强调是 strongly NP hard ，这可以排除对伪多项式时间（动态规划解背包这种算法）的期待。

这个其实很好理解，就是：

apply_many(x) = x + x^2 + x^3 + x^4 + ... = x + x (x + x^2 + x^3 + ...) = x + x apply_many(x)

如果你把 + 理解为列表拼接并把 * 理解为函数复合