每一个不曾起舞的日子,都是对生命的辜负。
在C语言中,我们已经学过程序的编译和链接,在这里将复习一下我们之前所学的内容并引出后续gcc/g++的内容。
如果我们直接gcc test.c 就会跳过上述四个过程直接编译生成最终的a.out可执行文件,因此我们不直接这样,而是划分成四条指令依次执行上述的四步翻译过程,在此过程中理解选项的含义。
首先我们要清楚,我们自己写的代码和库是两码事。C标准库是别人给我们准备好的,让我们直接使用的。我们所有使用库中函数的代码(printf()),其中我们自己只写了该函数的调用,没有对应的实现!只有当链接的时候,对应的实现才和我们的代码关联起来!
那么这就引入了链接,链接的本质:无非就是我们调用库函数的时候和标准库如何关联的问题。这种关联就包括动态和静态。
- 静态库是指编译链接时,把库文件的代码全部加入到可执行文件中,因此生成的文件比较大,但在运行时也就不再需要库文件了。其后缀名一般为“.a”
- 动态库与之相反,在编译链接时并没有把库文件的代码加入到可执行文件中,而是在程序执行时由运行时链接文件加载库,这样可以节省系统的开销。动态库一般后缀名为“.so”,如前面所述的 libc.so.6 就是动态库。gcc 在编译时默认使用动态库。完成了链接之后,gcc 就可以生成可执行文件,如下所示。
gcc hello.o –o hello
- gcc默认生成的二进制程序,是动态链接的,这点可以通过 file 命令验证。
事实上,对于动态和静态的理解,就好比在网吧还是家上网一样。如果你在网吧,此时网吧升级就会影响到你,这也就是所谓的动态;如果把网吧的电脑买来带回家上网,说明你已经有一台自己的电脑,相当于拷贝了一份网吧的电脑到自己家,上网就不会受到网吧升级时的影响,这就是所谓的静态。
因此经过定义与理解的总结:
动态链接: 受库升级或者被删除的影响,形成的可执行程序小,节省资源。
静态链接: 不受库升级或者被删除的影响,形成的可执行程序提交太大! – 网络,磁盘,内存
在Linux下库的命名:
即去掉前缀lib和相应的后缀,就是库的名字。举例:libc.so.6就是c标准库。
当我们执行查看c标准库的时候,就可以看到具体的信息,并发现此标准库默认是.so结尾的动态库。
对于动态库和静态库来说,动态库是系统自带的,即系统安装完毕就可以使用,而静态库则一般需要我们自己安装,这也说明了静态库并不是直接拷贝动态库的内容。因此我们需要手动安装一下静态库:
sudo yum install -y glibc-static
安装静态库定之后,我们就可以通过 在已有的指令基础上加上-static
指定静态库编译:
即系统本身,为了支持我们编程,给我们提供了标准库.h(告诉我们怎么用:标准的动静态库.so/.a)而对于此动静态链接,我们是基于Linux系统去演示的,事实上也只对Linux环境有效,但对于windows来说,其原理是一样的(windows下的动态库:.dll 静态库:.lib)
安装C++版本的gcc(g++):sudo yum install -y gcc-g++
- 会不会写makefile,从一个侧面说明了一个人是否具备完成大型工程的能力
- 一个工程中的源文件不计数,其按类型、功能、模块分别放在若干个目录中,makefile定义了一系列的规则来指定,哪些文件需要先编译,哪些文件需要后编译,哪些文件需要重新编译,甚至于进行更复杂的功能操作
- makefile带来的好处就是——“自动化编译”,一旦写好,只需要一个make命令,整个工程完全自动编译,极大的提高了软件开发的效率。
- make是一个命令工具,是一个解释makefile中指令的命令工具,一般来说,大多数的IDE都有这个命令,比如:Delphi的make,Visual C++的nmake,Linux下GNU的make。可见,makefile都成为了一种在工程方面的编译方法。
- make是一条命令,makefile是一个文件,两个搭配使用,完成项目自动化构建。
对于makefile,若想利用make命令,则必须创建makefile命名的文件(m大写也可),在内部编写一定的依赖规则之后,我们通过make就可以对应的执行程序,就省略了类似于这种gcc test.c -o test
的编译指令,好我们来看看如何操作:
步骤1: 创建makefile文件,并在makefile文件里编辑相应的依赖关系和依赖方法
**步骤2:**执行make指令并输出
这样最大的效果就是不用再写gcc编译了。
探讨makefile的原理,其最核心的内容就是依赖关系和依赖方法
那么什么是所谓的依赖关系和依赖方法呢?对于上面的步骤来说,在makefile文件中:第一行代表着依赖关系,也就是mycode这个要生成的文件是基于mycode.c实现的,mycode依赖于mycode.c。但仅仅有了依赖关系是不够的,需要明白这种关系是为了什么或者是继续什么原因才依赖的,也就是所谓的依赖方法,在第二行中,我们看到mycode是基于mycode.c经过gcc编译生成的,即gcc就是依赖方法。
就此例来说,第一行仍是依赖关系,但注意下面必须是tab造成的空格,而不是直接按四下空格。
此外,对于新增的clean来说,也是有一定意义的,.PHONY
:被改关键字修饰的对象是一个伪目标。我们知道在make时会生成mycode,通过clean这样的方式,就可以将其用make clean 删除:
对于.PHONY
来说:这个伪目标总是被执行的。那么如何理解这句话呢?
我们发现,当这个mycode已经是最新版本的情况·下,是不会再次gcc出来的。
修改后:
发现其仍然是可以执行的。这就是所谓的伪目标总是被执行的含义。
注:对于第一条指令来说,默认规定直接make就可以执行,就比如上面的gcc,这与make clean一样的完整写法make mycode来说是一样的。
对于上面的示例,我们知道了gcc对于已经是最新版本的生成的执行文件来说并不会将其改变,并会提示已经是最新版本,就上面的mycode.c来说,是mycode.c的modify时间不如mycode的modify时间晚,即是在最新的mycode.c下生成的mycode是不会被gcc再次编译生成的,这是由于mycode是基于mycode.c所创建出来的。
因此对于上面的.PHONY
的gcc来说,其能执行是因为.PHONY
规定之后,就不遵循这个所谓时间的规则。
为了演示推导过程,我们将makefile中的依赖关系进行拆分(但最终效果是一样的)
通过以上修改,我们退出vim模式并执行make
我们发现,对于makefile的依赖关系来说,是从上到下的,即mycode依赖于mycode.o,但此时并没有mycode.o,因此就需要找mycode.o的依赖对象mycode.s,mycode.s继续找他的依赖对象mycode.i,但mycode.i也并不存在,mycode.i就会找他的依赖对象mycode.c,mycode.c是存在的,因此执行情况是从下到上的。
但对于此推导规则,我们只需要明白其中的逻辑,真正利用makefile的时候,没必要将原来的一条gcc指令变成好几条指令。
基于mycode.c,我们在mycode.c中进行编写
我们发现,sleep尽管在printf语句的后面,但是显示器是仍然是先执行的sleep,这是什么原因呢?
实际上,这是一个行缓冲的问题,即确实在语言上先执行的printf,但却不是直接打印在显示器上,而是进入了缓冲区,而缓冲区是以\n为截止条件的,也就是说这一行中程序如果没有\n,就会暂时保留在缓冲区内部,直到出现\n或者程序执行完成。因此,上面的动图并没有直接执行printf是因为没有\n。
修改之后:
那我们看一下添加\n的演示:(动图)
添加\n之后就可以直接显示了。
对于回车换行,实际上是两个概念,换行\n是换到下一行,而回车\r是回到这一行的起始位置,因此我们键盘上的enter键称之为回车换行实际上是两个功能合并在了一起。
我们看一下回车\r的演示:(动图)
不显示的原因就是我们的回车\r将之前的内容给覆盖掉了,并且在缓冲区中回到了这一行的起始位置,因此程序结束也并没有打印。
因此为了解决上面的问题,可以用刷新缓冲区的办法实现:
修改完之后观察:(动图)
通过上面的了解,大家已经知道了缓冲区的概念,因此为了下面的进度条实现,在这里我们先通过上面的知识实现一下倒计时:
上述实际上有一定的细节,我们知道/r只是回到起始位置,但如果不控制格式2d,就会出现打印10,90,80……的情况,因为我们每次只覆盖了第一个位置,因此在这里要控制格式,并且fflush(stdout)。
这样就实现了一个简单的倒计时。
对于进度条来说,通过最上面的航缓冲的知识,我们已经知道应该如何去规避了,因此在这里直接展示进度条,我将程序分成三个部分,即经典的main.c/process.c/process.h,并且将makefile中的依赖对象也改变,对于依赖对象来说,只要-o后面最靠近的是要生成的即可。
进度条执行过程:(动图)
此外,我们还可以改变颜色:即在printf处进行修改:
演示:(动图)