@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)

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

看了半天，感觉问题的关键是 HCML 是否已经作为商标注册，如果没有的话可以尝试注册一下，这样 fork 者将不能合法使用这个名字。

> HMCL 的开发者只能宣布终止其 HMCL 的相关许可证权利。

这点比较微妙，如果你使用的 GPLv3 未经修改，那么即使 HCML 已经是注册商标，对方对注册商标的侵权似乎并不会无效化 GPLv3 授予的权利（这是两个分开的问题，因为 GPLv3 授予权利的条件似乎没有“不侵犯某个具体商标权”），而原作者是无法主动撤销 GPLv3 授予的权利的。

@YaakovZiv #18 这估计是延迟渲染内容的缘故。有些程序在“复制”的时候只是告诉 Windows 新的剪贴板有某些格式的内容，但不会直接把内容告诉 Windows （比如超级复杂的文档，提供剪贴板内容的程序可以同时提供文档、图片两种格式），另一个程序“粘贴”的时候会选择格式，如果某个格式的内容是“占位符”，那么 Windows 会让提供剪贴板的程序渲染该格式，然后交给读取剪贴板的程序。

粘贴的时候无响应是因为在等提供内容的程序渲染。复制后查看 Windows+V 不显示，是因为查看剪贴板和粘贴剪贴板不同，没有必要让程序把所有格式都费时费力渲染出来。（理同，在 Explorer 里面查看仅联网可用的文件占位符，或者是已经储存在磁带上本地无缓存的文件的时候，打开预览窗格不会导致文件被下载下来或从磁带读出，因为这个操作费时费力而且不必要。）

@ysc3839 #9 单纯是因为没有 IFileInUse 罢了，属于设计问题。

@acess #10 svchost 是比较著名的会多个服务一起用的情况，所有复用型进程外 COM 服务器都有这个问题。COM Surrogate 是把进程内服务器变成进程外服务器，属于做隔离的不同维度。

@acess #1 复制一下我刚写的评论：

答案自然是因为 COM 。文件的所有权不一定“来自”打开它的进程，或许是进程 A 用进程外 COM 服务器 B 打开了文件 C ，此时提示是 B 占用 C 是技术上正确，但对于普通用户无意义 /误导的信息，甚至可能鼓励自以为是的用户干掉进程 B 。例如一些文件在 svchost 里打开，但解决方法是关掉另一个程序。

这段代码含有未定义行为。

top 得到的引用在修改容器之后不再有效，pop 修改容器，因此 cur->next = node 触发未定义行为。

具体实现来说，priority_queue 可能的实现里，经过 pop 之后，你先前得到的 node 或许仍然引用有意义的位置，但那个位置等同于新的 top ，因此读取它可能会得到新的最大元。

@ClericPy #8 不太确定任务管理器能不能越过 DWM cloaking （我的猜想是不能，否则任务管理器会显示在所有的虚拟桌面上）。

另一个解决方法是常备两个账户（我自己是 Microsoft 账户设置为受限用户，内置管理员启用、改名、改密码、设置 PowerShell 为替换 Explorer 的 shell ，关闭 UAC ，用账户区分是否是高权限操作），出问题的时候可以切换到管理员干掉受限用户的 offending program 。

其实或许和内存没啥关系，单纯是 Explorer 设置 DWM Cloaking 的代码有 bug ，导致所有窗口都被 DWM 不显示，且只有任务切换器被渲染而已。这种 bug 还经常出现在 Edge 浏览器 /Office 窗口最大化、最小化、向下还原、Aero Peek 一系列操作短时间发生的情况（可能会出现最大化的窗口不显示，透出下方窗口，但是点击操作还是会进入没有显示的窗口上）。

以及我遇到这种问题的时候也是暴击几次 Windows 键，因为打开“开始”屏幕似乎也会 trigger 重新设置 cloaking 的过程，另一种方法是反复把鼠标挪到显示桌面的位置之类的，或许也会修复问题。

楼主是复制粘贴的错误信息吗？为什么有这么多错字？（ your 写成 our 、vour ，begin 写成 bean 。）如果是的话是不是要担心一下搞错网站被钓鱼。

目前我只知道 iOS Safari 有这个功能（分享—标注），而且不会换成 print media ，但我印象中超长网页会有截断的问题。

因为 /t/355321

“报告这个主题”