讯飞的产品都挺好的, 夸夸前东家. 不过听说今年因为疫情影响有点压力.

我觉得大家不必这么打击楼主, 大学可以拼搏一下! 我支持楼主创业!


毕竟还钱的人不是我.

菜鸟看到屎山会想办法重构然后被屎淹没，高手看到屎山会维持不倒塌的情况下再把自己的屎拉上去。

我现在在用某云厂的云存储 + CDN, sdk 拿到手稍微改一下加上了上传 /下载自动加解密的逻辑, 一年空间存储费 + 流量费也就 100 出头, 推荐试试, 比网盘好用

你这一套搞的太复杂了, 完全是公司服务器的作风. 我自己服务器上所有在跑的程序都是裸 go, 清爽的不要不要的

这种不知所谓的文章居然看完了. 首先佩服作者的勇气, 其次希望作者多看书, 等你大学毕业就会发现你在今天干了一件什么蠢事.

试了下编译器优化, 准备好板凳:

```c
int main() {
int s = 0;
for (int i = 0; i <= 100; i++) {
s += i;
}
return s;
}
```

```sh
$ gcc -o main -O3 main.c
```

```sh
$ objdump -d main

00000000000004f0 <main>:
4f0: b8 ba 13 00 00 mov $0x13ba,%eax <----------- 0x13ba == 5050
4f5: c3 retq
4f6: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
4fd: 00 00 00
```

所以我觉得最好的答案是 return 5050, 因为你已经在写代码的时候就做了编译器优化...

看 c 代码经常能看到 "我知道我在做什么" 的注释然后强制跳过编译器语法检查的…

个人看来这些规范，范式可以拿来用，但不必当教条，适合自己的开发习惯就好。

正常 endian 的逻辑，一般直接强制内存类型转换会快很多

端午牛逼

毕竟如果不每半年改个版公司就会发现有些职位似乎可以不要...

现在还记得第一次编译 llvm 时花了 39 小时。。。目前的话折腾了个云服务器，编译工作就扔上去不会中断本机的工作

close 是一个系统调用, 它出错的情况只有:

```
ERRORS
The close() system call will fail if:
[EBADF] fildes is not a valid, active file descriptor.
[EINTR] Its execution was interrupted by a signal.
[EIO] A previously-uncommitted write(2) encountered an input/output
error.
```

程序中经常遇到的是 EIO, 也就是在在 close 之前, read/write 已经报错了(比如文件 fd 已经提前关闭, 网络的话 TCP 连接已经断开等), 这种情况忽略 close 的 err 才是正确的逻辑. **因为调用 close 的核心目的是释放资源, 而不管在这次调用之前资源是否已经被释放了, 程序只保证在该次调用 close 后资源一定是已经释放的状态即可.**

=服务器前面挂一个反向代理, 反向代理里限制一下并发数就好了.

支持自己动手玩一下, 学一学 parser 和 compiler 也是好的.

水冷普遍噪音比风大，降温效果不如风，价格也更高…