……………………感觉是个天坑

强烈建议不要使任何对象实例成为全局对象，用一个工厂方法去获取唯一实例都好得多：

CSomeClass* getGlobalInstance(){
static CSomeClass *instance = nullptr;
if(!instance) instance = new CSomeClass{};
return instance;
}

c/c++里全局对象的初始化时间是不可控的（我是指代码监控不到生命周期），但起码在 exe/elf 里我还知道他起码在_start 之后.init 里调用或者在_WinMainCRTStartup 之后 main 之前（大概）调用，但你说放在 dll 里，它是在 dllmain 之后的什么地方调用的？完全没头绪。

std::thread 的源码也到_M_start_thread 就结束了，接下来完全是 c++ runtime 的实现，这在不同平台肯定又是不一样的，一个你得在对应平台自己调，一个你调出来了换个平台不一定还会复现，所以何必去踩呢

contributors 立即加入年尾 hr 约谈名单

所以等了半天还是一个进来说自己是啥行业的都没有

https://gcc.gnu.org/

20 年前的网页

容易吧

其实真的，支持 utf8 变量名是最好的

我倒是支持这种复杂命名直接上中文，比较麻烦的是数据库表名，感觉比较好的办法只能是缩写+留个翻译表

我也想知道。。因为我跟 lz 一个感觉。。。当然也一个行业

为啥会看不懂标题看不懂目的。。

就是想统计一下有裁员的厂子都是干什么的而已啊？

然后为啥给打码了。。

@lynntime 首先需要外接显示器，然后浏览器 ide 终端设全屏，触发角设置上，左手触摸板三指切，右手触发角

使用频率较低的窗口比如微信+qq+企业微信+finder 就堆在桌面上

前段时间也是在 v 站看到人发的

http://utf8everywhere.org/zh-cn

> UTF-8 编码在设计上保证了一个 ASCII 字符或子字符串永远不会匹配到一个多字节编码的字符中间。这在 UTF-16 中也适用。这两个编码中，多字节编码的码位的编码单元会将 MSB 设为 1。

> 此外，你还可以像在简单的字节数组中一样，直接在一个 UTF-8 编码的字符串中搜索 UTF-8 编码的非 ASCII 的子字符串——无需关注码位边界。这要归功于 UTF-8 的另一个设计特点——一个码位编码的起始字节永远不会与其他码位的尾随字节相同。


第一个字节的高位，在 utf8 中可用来判断这个码点编码成的 utf8 字节串有多长，而低位字节为了实现上面说到的设计，区间就不能包括开头字节的值

比如两位，低字节最多到 10111111，如果编码到 11000000，就无法与开头字节区分

我遇到过加载一个 so 内存泄露的问题，dlopen/close 内存是平衡的，但中途调多一个 api 就不平衡了
然后开了 asan 也没发现泄露，查了两天最后发现是 so 会自己 mmap 一块内存自己做内存管理，然后为了保证速度在 deallocate 之后还会预留一块内存以便下次分配加速，这时候 dlclose 它并不会自行 munmap，造成的泄露


我怀疑你遇到的是不是也是 hook 了 allocate/deallocate 造成的问题

半年， = 一学期

一学期学完一门课并且能真的用来写商业代码

自己掂量呗

反正在学校的时候这种人我们一般：“大佬太强了你之前绝对是学过的吧”

上兵伐谋，其次伐交，其次伐兵，其下攻城

上策：干一份想加班加班不想加不加的工作
其次：入职前交流好加班强度，摸清底细防止加班
下策：加班我就调休请假要加班工资
最次：打一架 /仲裁，离职后发帖：某某公司加班过度

好问题 学到了

1 1 1 随缘

hhhhhh


来来来，先举全人类之力， [想出一个值得举全人类之力的 Project]

你会觉得这想法真傻逼

对，你甚至可以期待一下崩坏……

https://www.youtube.com/watch?v=ve3kraPZSWA

街霸，铁拳，苍翼，guilty gear，今年的龙珠斗士

https://en.wikipedia.org/wiki/Evo_2018

token 的作用是一次性凭证

假设一次会话是 S1 -> B -> S2
S1 跟 S2 商定好 token，那么 S2 如果能接到 S1 的 token，证明此会话必有 S1 参与，不是 B 凭空造的，它防止的是 B -> S2 的流程未经 S1 授权，（或者说防止没请求过 S1 的什么 C -> S2 ）（ CSRF token ）

假设一次会话是 B -> S1 -> S2
这时候 S1 向 S2 出示 token，作用是防止 B 绕过 S1 的代理直接请求 S2 得到结果，此时 token 保证 S2 收到的请求一定是 S1 发起的而不是其它的什么服务器或浏览器本身 （ SSRF token ）

这些都是在不考虑信道，只考虑逻辑情况下的额外安全措施，首先信道不安全的话 token 可被窃取盗用那安全性是白搭，但就算信道安全，恶意代码也可能通过各种方式混入到请求中，比如存在 UGC 内容里，或者 XSS 从接受输入的地方混入了代码，token 主要防的是混入的第三方恶意请求