虽然这问题标记了 java，但是这个概念可不仅仅是 java 才有的

直接读的时候不一定能把内核提供的缓冲区读完，然后就得多次读，这样性能方面就会有问题，如果加个用户态的 buffer，就可以在检测到能读的时候尽可能多读一些，这样总的系统调用数量就会少很多（系统内是有缓冲机制，但是你每次去取，都需要额外的系统调用，一个系统调用的时间，可比你只复制内存慢多了）。

假设数据一次性到达 4096 字节，你一个字节一个字节读取，就要 4096 次系统调用，而有了用户态的缓冲区，就可以只发一次调用，然后后续的读就是内存复制了。

当然理论上如果你能控制到达数据的量的时候，是可以不用这样做的（然后更加高效），但是通常你是控制不了的，尤其是 tcp，就算你发送端以 1 字节为单位发，接收端也不一定能一次只收到一字节。。

字符串常量区啊

:doge:
说明抽象的不够彻底，你有抽象到代数结构上吗，把通用的逻辑转换成某种通用的代数结构，然后做一些代数结构上的操作，最后实现原本的需求任务

谁告诉你 sqlite 不支持多进程读写的。。。
只是同一时刻只能有一个写入事务或者多个读取事务而已，不同进程可以同时打开那个文件。。。
你做成网络服务，也不能干掉这个限制。。。
而且相对于其他数据库引擎也没有竞争力

你用 chrome 的页内搜索功能搜索前后两个字试试（

发错 tag 了吧

扩展不可能有这个权限做

虽然不知道发生了什么，但是你改成这样就能通过编译 https://godbolt.org/z/bq8sEn
另外你这个方法做 tuple 居然还需要 static_cast，这肯定和正确的做法有所偏离。。。

(建议加个判断，当用户已经编辑过就不要再覆盖了，不然用户大概会投诉

你在异想天开
先不说用 root 的 app 能不能支持这种情况
就说你改用户组这事就不可能，android 的用户机制是特殊设计的，app 所属的用户和组都是直接代码产生的（意思是 bionic 直接根据数字映射一个名字，让 top 里看着不会一堆数字，app 用户和组的关系也是代码写死的;每个 app 运行前会直接 setuid 和 setgid 到特定数字，和名字没有半毛钱关系），不由文件控制。。

官网除了首页和文档外其他都是空白的。。。

不只是加载变慢吧。。还会导致没有推送了

原生 hosts 大概无解了，不过既然都是 glibc 的“受害者”，自然可以用一个 nss 模块来解决，
大概参考这个（为模板）写一个自定义的 hosts 提供器即可（这玩意根本没实现 readme 里的功能，基本上就是一个模板）
https://github.com/apetresc/nss-hostslocal

好吧，第二点你理解错误了，按照 cppref 的写法，查找模板函数的时候类型参数会忽略默认值，于是这里第一种就是<typename VHead, typename... VTail, typename>这样的匹配模式（注意，这里和模板形参数的名字没关系），
而第二种的匹配模式就是<typename VHead, typename... VTail, std::enable_if_t<sizeof...(VTail)==sizeof...(Tail) >>
然后，还是一样的。。。
但是由于函数的参数列表不一样，所以和这个问题没有关联。（即使只有一个参数，VHead 推导的值也是不一样的，但是这里就是另外一个问题了。

你这情形 1 情形 2 不是一个东西么。。。
对应构造函数 1 的应该是 b{17, 3.14, "Hello world"}
1. 不是因为优先级高，而是因为构造函数 1 被吃掉了，enable_if 里不满足（俩 sizeof 结果不一样）。
至于为什么不这样写就不可以通过编译，是因为没有 enable_if 的时候 VTail = <空> VHead = <Tuple<...>> 也是符合函数声明的，直到跑到初始化列表（指 head(std...那个）才会出现错误，这时候已经无法挽回了
写了 enable_if_t 之后类型上 sizeof...(VTail) = 0 而 sizeof...(Tail) = 2 于是不相等直接 SFINAE 干掉了
第二点我再看看。。。

然后被当做致富手册给人搭桥？？

是啊,这个属于参数依赖名字查找的范畴
会在实例化的时候才进行决议
（当然了，如果不是参数依赖的名字，仍然按照原始的顺序进行查找
参考 ADL ODR 规则

xming 还是有 bug 的。。。比如 vscode 那种自绘窗口装饰的，就会在最大化的时候直接全屏