反正閑著也是閑著

正经的回答:

如果这两个 struct 真的只有名字不同，应该可以用 typedef 或#define。

既然需要当问题拿出来，我猜这两个 struct 不同内容。此时编译器需要的不仅是一个等价的"保证"，还需要知道一个 struct 的 member 怎样对应到另一个 struct。
编译器是不会去猜 member 的对应关系的，人都未必猜得出。你可以自己写一些 getter/setter 函数来实现 C 不提供的重载。

gtalk

@1dian01 一段时间以后才有。

#define B A

上一个版本在上一个 commit 里 (.git 下面)。程序只需要比较上一 commit 中的 tree 和你的 work tree (你修改的 **结果**)，不需要知道你中间做了什么，也不需要监视你的修改 **行为**。

用了五六年了? 第一台是罗技木星 后面都是 m570。感觉就是手腕完全不会疼了，练习后甚至可以玩 fps，wow raid

显然不是，你又不知道那个 commit 几时才发布

第一个在你写了很多条件后会变成▶，不 scalable。

第二个就一直是■，只是长一些。

钱和做出来的东西的价值甚至不是线性的。花多少钱做多少事，很合理。

他的文章应该帮助了很多人入门。科普用的文章深度不够或有漏误是正常的，我觉得不必求全责备。

#9 的补充: 最后一段 "内部所有 blob 的 sha1" 是指那个 blob 路径中的 sha1，不是内容的。

可以当 swap。如果文件系统支持，如 zfs，也可以用作文件系统的缓存。

我在本地简单实验了一下:

1. 建立 repo A，commit 某个文件
2. 把 repo A 中那个文件对应的 blob 换成另外内容
3. git clone A B 能正常结束，B 中的这个文件会是改过的 blob 的内容。
4. 此时在 A 和 B 中运行 git fsck 都会说 `error: sha1 mismatch for .git/objects/8f/150a442a97cd4ad6320768029b7a1e13a42ca2 (expected 8f150a442a97cd4ad6320768029b7a1e13a42ca2)
`。但 fsck 不会自动运行。

因此即使一个 commit 和内部所有 blob 的 sha1 都和原 repo 一样，仍然有可能内容是被篡改过的。这样的篡改可以用 git fsck 检查出来。不知道 github 对这种事情有没有预防。

*无限循环小数

一个数是 model，用几进制写出来只是 view。无限不循环小数显然不等于无理数，在几进制都一样。

一般入门是会和某种 API 一起学的，先简单用起来再慢慢扩充并解决问题。

(线程 / 同步 / 相关 API) 这些概念高度杂合，在建立知识体系后可能觉得一个单独概念并不难懂，但是初学时要同时领悟就很不容易。

我觉得存在本身的原因是... 因为有人定义了能产生无理数的运算。
整数的加减乘除的闭包得不到无理数。如果没有定义方根，可能很久后人们才会因为别的原因发现第一个无理数。