2015年11月17日 17:09:46

有一个很好的链接：Standard C 语言标准函数库速查。不在其中的自然就不是 C 标准库中的函数，不过有一点点瑕疵，这个速查的搜索功能不好用。

1. 即便是标准库中的函数，在不同平台也是会有差异的（但标准规定的部分应该是相同的）。比如：fflush、fopen；
2. 不在标准库中的函数：不同的平台使用了相似（甚至相同）的名字实现了相似的功能，所谓“相似”则必然有不同，其中的区别就是我们编码过程中的陷阱！（极端一点）可以认为只是不同平台不同实现选择了相同的名字而已。比如：snprintf、access 并不是标准 c 标准或者 c++ 标准中规定的函数。

事情源于我想将局域网内服务器上的代码上传到互联网上的远程仓库：repo-133 -> repo-E431 -> repo-remote

• 代码编写以及编译运行只能在 133 服务器上，此机器无法连接互联网；
• 133 服务器可以访问我自己的笔记本 E431，毕竟我要通过 xshell 访问 133 进行开发；
• E431 笔记本可以访问互联网，针对私有代码我一般使用开源中国作为远程仓库。

实现这个打算很容易，问题出在精益求精的摸索过程中。我在 E431 上中转时使用的是 Bitvise SSH Server，搭建方法参考 在 Windows 上搭建 Git 服务器。（我在 E431 上建立的并不是裸仓库）搭建完毕，从 repo-133 向其推送时会失败：git “fatal: no matching remote head”，当时因为有别的工作，通过将 repo-E431 检出一个无用分支规避错误。

在之前的笔记中讲过 Git 的分支操作，无论简单还是深奥，那些都是一个仓库内的事情。今天这篇笔记重点描述两个仓库之间的联系，涉及到的 git 命令有 pull、push、clone 等，难点围绕着两个概念： remote-tracking branch 和 tracing branch。

序

如果接触过 github，或者国内的 OSChina，那么必然用过 git clone 命令。我一般是这么用的：

1. 先在 github 上创建一个仓库（有时候还会捎带着使用 README.md 文件）；
2. 然后使用 git clone 克隆到本地；
3. 在本地进行文件添加、修改等操作后 commit；
4. 在本地执行 push 推送到远程仓库（有时候还会将本地新增的 branch 也 push 上去）。

以前整理过一篇笔记 《初始化》，前两天又翻出来浏览了一下，写得很烂。限于当时的水平，并未像现在这样透彻的理解“默认构造函数”、“拷贝构造函数”、“拷贝赋值运算符”等概念，读书《C++ Primer》时看到好多种“初始化”，整理出那一篇可能只是想罗列名字、定义，让自己知道哪个是哪个罢了，却并不深刻理解中间的关联与区别。我们从头再来。

讲 C++ 的初始化，我们有好几种切入的方式：

• 可以从日常使用的形式，从我们惯用的代码讲起，引出相关的术语；
• 可以直接讲构造函数，构造函数是本质，初始化是呈现，理解了构造函数，也就理解了初始化；
• 可以罗列各种初始化的表现形式，然后归纳，总结出结论。

前一篇笔记带有第三种切入方式的味道，罗列了很多“XX初始化”，却没有归纳总结，意义不大。这一篇笔记我想以前两种方式来写。

POD 类型是一个神神道道的概念，有点反人类。好在大多时候我们并不需要涉及这个概念，即便在一些场景中用到了，C++11 新增的 3 个与之有关的判断也足够了。

概念

关于这个概念，在 C++11 之前使用了很多的限定来概括出它（貌似源于《imperfect c++》）。C++11 则给出了新的定义。关于其限定，我整理了 维基百科 - pod 得到下图：

这个其实是用思维导图软件 Mindjet 做的，原稿下载。用思维导图来整理 pod 的概念比 markdown 更合适。

Markdown 简洁好用是毋庸置疑的。但是在使用中碰到过以下几个困惑：

1. 第一次想在 wiz 中使用 Markdown 笔记时，查阅 为知笔记 Markdown 新手指南 发现代码的渲染效果挺好，挺喜欢的。可实际上把我在 MarkdownPad2 中写好的笔记拷贝过去时，发现代码的渲染效果和 MarkdownPad2 中一样素净，并没有语法高亮。进而发现两者关于代码的语法定义是有区别的。

2. 不单单代码，在 为知笔记 Markdown 新手指南 中提到的好些特性我在 MarkdownPad2 中并不能使用：

   如果你是名程序员，那么可以用 ``` 把代码块包起来，渲染后可以关键字高亮

   删除线：在文字前后添加 ~~

   目录

3. 在手机上购买 jotterpad 之后，发现代码部分的渲染效果和 MarkdownPad2 也不一样，更加的不起眼，导致最开始时我还以为 jotterpad 不识别代码语法呢。

正文

直到今天（2016年6月1号）才发现，Markdown 是存在标准之乱的。从最早的 Markdown诞生（称为传统 Markdown，Markdown Basics等），流行起来之后各种扩展，在 GitHub 上最盛行的 GitHub Flavored Markdown (GFM)， 做标准的 CommonMark。

其中，做标准让大家欣喜，Markdown 发布标准了（借此理解行末两空格的意义），但也遇到了 极大的困难，理解英文有困难的话可以看 Markdown的标准化之路。

应用

关于三款应用：

1. 为知笔记使用哪种标准？在其官网未找到相关说明。猜测至少是以GFM为蓝本的，甚至就是用的GFM。

2. MarkdownPad2 可以更改“Markdown 处理器”。默认使用第一个

   

3. 在 jotterpad 的官网提示如下：

   JotterPad renders Markdown (CommonMark) syntax.

语法

关于语法（中文）：

1. 传统 Markdown
2. GFM 格式说明
3. CommonMark Spec
4. * Markdown 书写风格指南
5. Markdown标准语法与GitHub Flavored Markdown语法大全

选择

关于 CommonMark：虽然不读英文，想来是撕逼过的。

CommonMark，最早的名字叫 Standard Markdown，后来迫于 Markdown 原作者 John Gruber 的压力而改名。

有人觉得“无规矩不成方圆”，没有标准的话未来发展空间有限；也有同志认为正是因为没有标准，才会出现各种扩展，百花齐放。

扩展阅读：

1. Markdown and CommonMark
2. 互联网中的左派与右派

其实，操那么多心做什么，作为程序员，哪块用得着拿哪块，用不着的少参与。

争论并不重要，重要的是 选择使用正确的 Markdown Parser

ps 这篇备忘录整理完之后命名为《Markdown 标准之乱》，在半年以后（2016/12/15 16:40:38 ）发布时改为现在的名字。内容未做任何修改，我觉得原先的标题是整理的初衷与当时的感慨，但并不切合整理后成稿的内容。况且我现在用 Markdown 基本就是在用 GFM 了，半年前的困扰和选择已然过去了。

书山有路勤为径

有料

• 编程随想的博客
• 阮一峰的网络日志
• 杨飞工作室
• 電腦玩物
• 少数派-Android
• 雨声

专业

• Linux工具快速教程
• Linux 中文知识库
• 有哪些实用的计算机相关技能，可以在一天内学会？
• C++11 并发指南系列 - cnblogs

其实很简单的：甭管是打包还是压缩，参数一般以 vf 结尾，后跟包名称；打包的情况就是从 c（打包） x（解包） t（查看） 中挑一个；有压缩的话再从 z（gzip） j（bzip2） 中挑一个。Ok， 打完收工。

1. 如果打包的文件很多很多，造成刷屏，就需要把 v 参数去掉；
2. 包中追加（r）、更新（u）内容，使用率一般不是很高；

2015年12月11日 14:53:34

通常情况下，对函数库的链接是放在编译时期（compile time）完成的，所有相关的对象文件（object file）与牵涉到的函数库（library）被链接合成一个可执行文件（executable file）。程序在运行时，与函数库再无瓜葛，因为所有需要的函数已拷贝到自己门下。所以这些函数库被成为静态库（static libaray），通常文件名为“libxxx.a”的形式。
其实，我们也可以把对一些库函数的链接载入推迟到程序运行的时期（runtime），这就是如雷贯耳的动态链接库（dynamic link library）技术。

静态库概念

1. 库是预编译的目标文件（object files）的集合，它们可以被链接进程序。静态库以后缀为“.a”的特殊的存档（archive file）存储。
2. 标准系统库可在目录 /usr/lib 与 /lib 中找到。比如，在类 Unix 系统中 C 语言的数学库一般存储为文件 /usr/lib/libm.a。该库中函数的原型声明在头文件 /usr/include/math.h 中。
3. C 标准库本身存储为 /usr/lib/libc.a，它包含 ANSI/ISO 标准指定的函数，比如 printf。对每一个 C 程序来说，libc.a 都默认被链接。
4. 静态库的优点是可以在不用重新编译程序库代码的情况下，进行程序的重新链接，这种方法节省了编译过程的时间（在编译大型程序的时候，需要花费很长的时间）。静态库的另一个优点是开发者可以提供库文件给使用的人员，不用开放源代码，这是库函数提供者经常采用的手段。

姊妹篇 《Makefile 入门》 中已经介绍过隐含规则、自动推导。要想在 make & Makefile 上精进，必须了解其隐含规则。它可以让你省去很多繁琐、重复的细节，快速高效地完成项目的编译和链接。

隐含规则依赖同名（同名源文件-同名目标文件-同名可执行文件），一般而言设置好编译器属性、给出必要的头文件目录，就可以使用隐含规则生成同名的目标文件（.o 文件）；但实际项目中很少出现可执行文件由单独一个源文件/目标文件生成的情况，所以生成可执行文件（包括链接库）时一般不能只使用隐含规则达到目的。