@elfive
你说的这个不适用于直接返回 const std::string & 的情况，
const std::string &foo();
const std::string &bar = foo(); /* 悬空引用 */

但是可以延长直接返回 std::string 临时对象的生命周期。
std::string foo();
const std::string &bar = foo();
上述代码是没问题的

@lau52y
location /xxxxx {
return 301 http://a.com$request_uri;
}

location = /1.html {
return 301 http://a.com/1.html;
}

vim 党表示为了 touch bar 从按 esc 改成了按^[
然后发现这样比按 esc 更舒服😌

试试一行一行地把你的原始 predict.py 里的 import xxx 加到后面极简 predict.py 里面，看加到哪一个开始返回 NULL 的

@youthfire
more -> accessibility -> aggressive rejection 打开看看

quantumult 么，软件名都不说

等待下一个 pptos 然后抢建一个 awesome-pptos

h2 的 server push 居然没人提…

假定 lz 说的速度是指一个网址从按下回车到渲染完毕的延时，两种情况都需要 dns 参与
在 h2+tls 的情况下，首次链接的 tls 握手带来的延时是不可忽略的，这一步就是比无 tls 情况的 http1.1 慢。而后面浏览器加载这个页面的其他资源的时候情况就不一样了，

首先就是 server push，一般会把一些 js css 跟随第一个页面一起推给客户端，这里 http1 一个一个去发 request 给服务器；

然后就是多路复用，同个域名下的若干个链接可以公用一个 tcp+tls session，这也省下了一部分延时；

还有就是 h2 的头压缩，在网页需要 http 头携带很多信息的情况下头压缩带来的好处也是很明显的。

因此，对于一个复杂的站点来说，h2+tls 确实有可能做到比普通 http1 更快。但是对于简单页面，那毫无疑问是普通 http1 快。

可以利用 fetch 断点续传

先本地建一个空的仓库，git remote 添加你的远程仓库名字，然后 git fetch 就行了，断了再接着 fetch

fetch 完直接 checkout 就好

@tengtengking #16
你可以在编译选项里加上 `-fsanitize=address -fno-omit-frame-pointer` 让 gcc 插入 sanitizer 的代码，再复现问题看看报错

@tengtengking

那么可能是哪里的内存越界把堆栈破坏了所以 gdb 没法回溯这里的返回地址，也可能是你的 libc 或者 libpthread 没有 unwind 符号。这种情况下 gdb 几乎没什么作用，需要其他信息。

有日志吗？从日志内容能推出大致什么地方出的错么？是私有项目么？

@augustheart
这个程序是在进入 main 之后崩溃的么，根据你贴出来的这点信息，好像连 main 函数都没进去就崩了

这个 bt 结果很奇怪啊，为什么起始 rip 是 0x0000000000000000 呢，感觉 binary 或者 core 也有问题

@maiganne #14
解决了的话最好把方法分享出来，这样以后有人遇到同样的问题搜索到这个帖子可以进行参考。

我记得关闭的时候会有选项的，然后旧的 iCloud 文件夹会被移动到 ~/iCloud Drive(Archived)

@maiganne #5
方便把
curl -v http://localhost:80
的执行结果贴出来嘛