Da'Inihlus

可以考虑用枚举表达常用的、能由用户构造的类型。其他的塞进一个other枚举里。在map里存`{type,data}`，或者用其他更直观的表示（其实要用的都已经在前面所说的情况里了，很可能是根本用不上）。 实际上现在这个对于无法辨认的CQ码就用`unimpl`表示类型。并且为那些返回`MessageSegment`类型的static方法提供了枚举型支持。

`INVALID_TARGET`的确是没找到哪里有用到。（总之先摆一个这里放着。）

上面是说[这里](https://github.com/cqmoe/cqcppsdk/blob/master/src/core/api.hpp#L19)有个`INVALID_TARGET`，但是并没有在sdk其他地方用到。（看来是个有些影响的重构问题。）

类似的，我不认为要围绕酷Q作出完整支持，而是围绕用户，对用户需要的、常用部分作出一定支持。 从这个角度来看，sdk已经将酷Q接口封装，errcode对于用户其实完全看不到，这反而不能在这个角度上帮助到用户。

这个能行 ```cmd python -m uiautomator2 init ``` 具体来说是Alas卡住了停止后，用这个，然后再启动能救活 我目前理解的代码上解决的办法是在这个地方 https://github.com/LmeSzinc/AzurLaneAutoScript/blob/4dbc7913b47a571cd984fddbc2fd225c04f42bc2/module/handler/login.py#L151-L162 在L159和L160中间加个 ```python self.device.restart_atx() ``` 我先摆着看看情况（

其实另外一部分就提到了 > 不够全面——可以向上、向下、**旁支**转换。 如下： ```C++ struct B1 { virtual f1();}; struct B2 { virtual f2();}; struct D: B1, B2 {}; void fun(B1 *p) { auto p = dynamic_cast(p); } ```...

> ```c++ > int main() { > std::cout th.detach(); > std::cout ExitThread(0); > #else > pthread_exit(0); > #endif > } > ``` `ExitThread(0);`会导致问题 例如在main前面加一个 ``` C++ struct foo { foo()...

你看看这3秒后test_thread，5秒后test_exit，是不是怎么看怎么是join。该join就join。 我认为是不能在main里又ExitThread又std::exit的，显然会导致不少资源double free ExitThread: > When this function is called (either explicitly or by returning from a thread procedure), the current thread's stack is deallocated, all **pending I/O initiated by...

这整个讨论不就是说detach的错误使用方式，指望detach线程在主线程结束之后的行为是错误设计。 1. 这里需要test_exit在test_thread产生顺序关系本身就该用join了。在独立线程里执行的3秒后5秒后你既然说这并不是真的3秒后5秒后，那肯定就是没有顺序关系呗，那这里显然实现了一个data race。 1. 我只是打错了，又在main里面ExitThread又std::exit，这并不改变判断，我就是说明ExitThread虽然没以C++形式回收资源，但还是清理了IO等资源的，从其他线程调用std::exit回收资源会显然造成这部分的重复回收。

其实还看了一下 _endthreadex 直接标记了这么个玩意儿 > For an executable file linked with Libcmt.lib, do not call the Win32 [ExitThread](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-exitthread) API; this prevents the run-time system from reclaiming allocated resources. _endthread and _endthreadex...