aheadlead的博客超越未来搜索主菜单跳至主内容区域跳至副内容区域首页用Vim写程序闲置物品关于我文章导航← 早期文章来读好文（1）发表于2014 年 1 月 20 日由aheadlead3除了经典名著，互联网上也有不少好的文章可供学习。我每周会要阅读不少文章，其中不乏非常优秀的内容。收集在此，既是一种分享，也算是一种收藏。<C/C++> 左值和右值, L-value和R-value看C99标准的时候经常会出现lvalue和rvalue这两个单词，然而，一直以来我都不太清楚这两个词的意思。有位少年问我C语言里面这么写为何错了：int Arr[10];int *pArr = Arr;(Arr+1) = 1;我竟然一时还回答不上来，只知道这个是错的。脑袋里面冒出rvalue和lvalue这两个词，自己却不知道什么意思……看看这篇文章有好处的。Help – IBM Mac OS X: Lvalues and Rvalues这篇文章是上面“<C/C++> 左值和右值, L-value和R-value”的一个补充，如果你不厌恶英语的话，读读这个也很好。C语言格式输出函数printf()详解我在这里才知道printf的很多用法……【转】 尽量不浪费压制时间的简单视频高压要点这篇文章是教你如何压视频压得比较好的，尽管我还没有试验过。浮点数的二进制表示这篇文章很好的讲解了二进制数在电脑里面的存法～知乎：12306 外包给阿里巴巴、IBM 等大企业做是否可行？pdf打包：下载发表在互联网| 标签有12306、printf、左值和右值、浮点数、高压| 3条回复进一步理解函数调用中数组的传递方法发表于2014 年 1 月 13 日由aheadlead3void foo(int arr[]){arr[0] = 213;return;}int main(){int d[10] = {0};foo(d);return(0);}请看看这段程序，当执行完main()中的foo(d)后，main()中的数组d中的第一个元素d[0]的值是多少？我知道肯定有说213的。很好，你说出了正确的答案。但也一定会有说答案是0的。“为什么是213啊？老师说了修改形式参数并不会改变实际参数啊。”你可能会问。继续阅读 →发表在C语言基础| 标签有函数、参数、数组| 3条回复关于修复iPhoto损坏的视频的研究记录发表于2014 年 1 月 7 日由aheadlead4昨天晚上兴致来了，想做个高中的回忆视频自己看。在iMovie里面倒腾了半天，麻蛋发现我的高中的拍的录像统统挂了。回想起iPhoto最近大升级，我还开开心心的跟着iPhoto把iPhoto Library升了级。结果就成这样了。买了个表啊，这是我高中的珍贵记录，怎么能说丢就丢呢？顺便说一下，Pages升级到了最新版也是经常崩溃，写个文章真作死，写一行崩溃一次，我也不知道什么原因。反正对Apple的失望又增加了几分。我常说Apple的东西不需要用户操很多心，今天可算是抽了Apple一耳光了。虽然我的确没有什么严格的证据证明是iPhoto搞的鬼，但是……根据网上的一些资料，我们假设是iPhoto搞的鬼吧……要不然没法给文章取标题了。损坏了的视频在iPhoto里面是这种形态：（可能会泄漏隐私的部分均已马赛克伺候）你可能觉得什么都没看到…可损坏了的视频的确就是什么都看不到。我用了个简单的办法，把视频从iPhoto Library里面复制了一份出来，好在我这个视频以前有备份，备份是能正常播放的。可恶的是我还有一些视频没有备份。我打算从这两个文件的差异中寻找真相。IMG_0330_bad.MOV是挂了的文件IMG_0330.MOV是我以前备份的文件（备份多么重要！）可见，在图标上已经无法预览视频内容了。打开文件简介，也是如此坑爹：损坏的视频无法看到视频的各种参数，另一个正常的视频可以。用QuickTime打开损坏的视频，则是这样的：好的，接下来我们进入正题。由于我的iPhoto Library是存在移动硬盘上的，或许是有时没有卸载（弹出）驱动器导致文件丢失，所以我用磁盘工具（chkdsk in Windows）修复了一遍磁盘，结果没用。其实仔细想想，要是真的能用磁盘工具查出错，那我怎么能把这个文件复制出来呢？观察文件大小，发现IMG_0330_bad.MOV和IMG_0330.MOV的大小都是290,325,815字节。用hexdump查看IMG_0330_bad.MOV的内容，发现不是令人沮丧的全0。所以，我可以猜测，这两个文件的大部分内容还是相同的，只有小部分被破坏了。随后，我用cmp比较两个文件的差异。得到如下结果：MacBook-Pro:iphoto_damage_video aheadlead$ cmp -l IMG_0330.MOV IMG_0330_bad.MOV 1   0 3652   0   1......（中间部分的数据省略了）510 365   0511 165   0512 234   0限于篇幅，我把中间的部分省去了。中间的部分几乎都不一样，反正写出来也没谁看的懂（除了专门挖掘这些数据的少年们）。反正得到的结论就是，这两个文件的前512个字节是不一样的。正好最近学了C语言读写二进制文件，而且linux的dd命令总怕用出错，我就写个程序试一试能否通过替换文件头的形式来使IMG_0330_bad.MOV恢复正常。BTW，还是提一下，笔者的编译环境为：Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)Target: x86_64-apple-darwin13.0.0Thread model: posix这个程序就懒得做异常处理了……#include <stdio.h>int main(){FILE *in, *out;char buf[1024];in = fopen("IMG_0330.MOV", "rb");out = fopen("IMG_0330_repaired.MOV", "wb");const int header_length = 512;fread(buf, 1, header_length, in);fwrite(buf, 1, header_length, out);fclose(in);in = fopen("IMG_0330_bad.MOV", "rb");fseek(in, header_length, SEEK_SET);for (int length = -1; length != 0; ){length = fread(buf, 1, 1024, in);