@mumbler IDE 都是大型软件，不过编译器解释器之类的倒是有一些体量不大的可以看看。个人推荐感兴趣的话可以看看 Lua 语言的编译器和解释器，代码很清楚，量也不大。

终端模拟器是 terminal emulator，对应的“终端”是指的物理的输入输出设备 —— 古老一点的比如电传打字机，现代一点的 就是键盘+显示器的组合
console （控制台）是另外一个东西，是指放整个机器可交互部分的那个字面意义上的一个平台或者说一张桌子，包括 terminal，也包括机器的前面板。现代机器的面板上也就只有开机键复位键这寥寥几个按钮了，但是古老一些的计算机在面板上可能会有老大两排按钮，比如输入初始化的指令之类的时候能用得上。

鼠标是个啥鼠标？蓝牙的还是有线的？有没有试过拔了重插一下……

@mahaonan1994 所以要不你还是弄个 Adobe Illustrator 之类的软件照着这个样子做一个矢量 svg 吧。

你这压根就不是个矢量图，而是在 svg 里又插了个点阵图……你用什么工具生成的啊……
你要是真打算用点阵图的话还不如直接用 png 甚至 jpg……

@msg7086 指令集 JIT 翻译固然不快但是也没慢到十分之一到几十分之一的地步啊……

不如先排查一下自己的惯用扩展里有没有哪个不太对劲……

另外 E 开头那些个是 Intellisense 报告的问题。Intellisense 用的是 EDG 开发的 c++前端，不是微软自己的产品，所以我猜可能是因为这个原因所以文档上找不到

虽然不知道为啥不是从 0 开始的，不过至少可以确认的是
C999 是 Fatal error UNKNOWN MESSAGE
C1001 到 1999 是 Compiler Fatal Error
C2000 到 3999 是 Compiler Error
C4000 到 5999 是 Compiler Warning
再往上的编码是一些 Code analysis warning 之类的东西……
大体上是这样，中间穿插了一些奇怪的东西，比如 C1xxx 段里面还有几个 Code analysis 出错了的消息之类的。

@neoblackcap 按照 https://en.cppreference.com/w/cpp/compiler_support 这里给出的信息，gcc 、clang 、msvc 三家里，clang 的进度是最慢的一个……

相比之下，type[] array 这种风格的声明是更直接的一种：声明的左半部分是“被声明变量本身的类型”，右半部分是“被声明变量的名字”。
这种写法确实更符合更多人的直觉（对数组类型还不太明显，但是如果你写一个返回函数指针的函数指针就能明白 c 语言的那种风格有多不直观了），所以比较新的语言更多地都是采用 type[] array 风格的。

c 语言的所有类型声明都遵守一个基本的格式：一个“类型” + 一个“用法范例”，数组也不例外
就以数组声明为例子：
int array[1000]
这个意思是说，如果我们按照
array[整数]
这样的格式写一个表达式，就能得到一个 int 型的结果。

如果说数组声明对这个格式的体现还不太明显的话，可以看看函数指针的声明：
int (*p) (int, int)
这表示，如果我们按照
(*p)(整数, 整数)
这样的格式写一个表达式，就会得到一个 int 型的结果。

所以总结下来，c 语言声明语句最左侧其实是写的“这个变量在正确使用后会得到一个什么类型的结果”而不是“这个变量本身是什么类型”，而除开最左边的那个类型之外，声明的右半部分其实是对被声明变量的使用方法的一个示例。

@amiwrong123 “我这么理解没错把。” —— 不完全正确。async 函数会返回一个 future 类型的右值，然后这个右值触发了 shared_future 的一个构造函数 [shared_future( future<T>&& other ) noexcept] ；此时 future 的内部状态会被移动到 shared_future 里——如果你对 c++的“移动”这一概念不太熟悉的话，你可以简单理解为 future 的某些成员变量被先拷贝到 shared_future 里面，然后 future 里这些已经被拷贝过的变量就全部清空为 null 了。所以正常情况下，这个被移动过的 future 在析构的时候会检查自己的成员变量，发现是 null，就不会做 delete 之类的操作。
将一个 shared_future 拷贝给另一个 shared_future 的话，默认执行的则不是移动而是拷贝构造 /赋值函数。shared_future 内的“状态”（通常是一个指针）确实会发生浅拷贝，但是在浅拷贝的同时还会有一个引用计数+1 的操作； shared_future 在析构的时候是会检查引用计数的，所以并不应该发生错误 delete 两次的问题。
事实上 future 和 shared_future 之间的关系有点类似于智能指针里的 unique_ptr 和 shared_ptr，你可以类比着理解一下。

另外我又仔细想了想你这个应用场景，感觉你完全用不着用 async 和 future 这套东西啊。你的消息队列完全只需要是一个 std::vector<std::function<void()>>就可以了。你这里用 async 只会增加 debug 难度……

虽然不知道是为啥，但是有一点很有趣的就是，你这个报错的好像是 std::future 的析构函数而不是 std::shared_future 的析构函数。似乎 std::async 返回的 std::future 在已经被 moved 的情况下，析构的时候却爆炸了。
你这个场景里有什么必须使用 std::shared_future 的必要么？能不能直接用 std::future ？说不定避开“析构已经 moved 的 std::future”就能绕过这个问题？

@QBugHunter WPS 是开源软件？

@mara1 mac 上写 c#可以试试 Rider 这个 IDE

但是既然只是用 xp 看 IE 的话为啥要换 ssd 呢……

Win10 已经全面接管了相关设置，所以这个就在系统设置里设置就好了，显卡控制面板已经不管这个了