专治各种不服

<br />#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))<br />这个宏为编译时判断e是否为0<br />假如e等于非0值，则!(e)为0，则!!(e)为1。再struct{int:-1}则会编译出错。<br />假如e等于0，则!(e)为1，则!!(e)为0。再struct{int:-0}，实际等价于struct{int:0}则编译通过。<br /> 

前阵的时候领导提出要对memcpy做一个测试。也没有交代具体的细节。我就直接自已写了个常规memcpy，然后再把内核的__memcpy和glibc的memcpy整出来，对三者进行比较，不比不知道，一比吓一大跳。测试结论是：kernel和glibc的memcpy性能良好，glibc比内核的略高。自已写的就惨不忍睹了。测试程序大概是先定义两块1G的全局内存。然后先用memset将其全置

本文允许转载。转载请注明出处：http://blog.youkuaiyun.com/z2007b作者：无为和尚非易失性存储设备写数据时掉电恢复是一个比较头痛的问题，如果写入数据写入到一半的时候掉电，数据的完整性就没法得到保证，本文提出的方法是在不增加新硬件的情况下，完成掉电恢复的一个策略，但是本文介绍的方法没法保证数据逻辑上的完整性。比如你要写入的数据需要在A处写1，在B处写2，才能保证功能的正确性，如果这两步操作是分开的，并且你在写A的时候掉电了，那么可以恢复A，但是没法恢复B。就保证不是AB这个大集合的完整性。只能

一直都想写点“深”层次的东西，总停留在代码层面确实不够腕，当然啦，我也不是什么腕。^_^上面这些都可以当个笑话，但其实也是有一定意义的，最少细心的人会想到我要表达的思想：只停留在代码层面的不是腕。是的，我是这么认为的。但至于什么才算是腕，这个我真不知道。因为我目前也不是腕，所以没法对一个压根不了解的东西做总结。既然不是腕那我们就还是回到代码的层面讨论吧。我只想说一句：千万不要走野路

当年刚进大学时，爷老子送我，临走时，娘老子哭了，我一脸不耐烦。毕业后上班了，外公逝世时，我回家了，临走时，娘老子哭了，我抱着她安慰说，一切放心。今年过年，我回家了，临走时，爷老子，娘老子和我三个人抱着哭成一团。明年？...