菜单

对于C语言可移植性的思考

2020年3月13日 - 计算机服务器
对于C语言可移植性的思考

本文首先提出平台相关代码造成的两个问题,然后针对这两个问题循序渐进依次提出解决方案,在分析了前两个方案弱点的基础上,最后着重介绍一种基于多种设计模式的
Linux 平台相关代码的解决方案,并给出此方案的 C++ 实现。

 
我相信学过C语言的同学,都会在书中看到C语言特点一定有:可移植性。但是什么是可移植?如何才能可移植?C语言是如何做到可移植的?对于初学者,可移植可能是一个经常遇到却很神秘的词。我想通过这篇文章来表达我对于可移植性的一些想法。

Linux 平台相关代码带来的问题

目前市场上存在着许多不同的 Linux 平台(例如:RedHat, Ubuntu, Suse
等),各大厂商和社区都在针对自己支持的平台进行优化,为使用者带来诸多方便的同时也对软件研发人员在进行编码时带来不少问题:

  1. 由于程序中不可避免的存在平台相关代码(系统调用等),软件研发人员为了保证自己的产品在各个
    Linux
    平台上运行顺畅,一般都需要在源代码中大量使用预编译参数,这样会大大降低程序的可读性和可维护性。
  2. 接口平台无关性的原则是研发人员必须遵循的准则。但是在处理平台相关代码时如果处理不当,此原则很有可能被破坏,导致不良的编码风格,影响代码的扩展和维护。

本文将针对这两个问题循序渐进依次提出解决方案。

   
首先,在这里铺垫一下。学过Win32程序设计的人肯定都听说过APIApplication
Program
Interface)。我就先说说API,高手绕过。API对于程序员来说就是系统提供的接口,任何涉及系统调用都要通过API来完成。对于不同的操作系统都有不同的一套API,也就是说对于不同的操作系统系统调用的接口是完全不同的。所以在API层我们是不能移植的。

 

通过设置预编译选项来处理平台相关代码

通过为每个平台设置相关的预编译宏能够解决 Linux
平台相关代码的问题,实际情况下,很多软件开发人员也乐于单独使用这种方法来解决问题。

假设现有一动态库 Results.so,SomeFunction()
是该库的一个导出函数,该库同时为 Rhel,Suse,Ubuntu 等三个平台的 Linux
上层程序服务。(后文例子均基于此例并予以扩展。)

      
下面我就来说说可移植,可移植顾名思义就是可以从一个平台移植到另外一个平台,但是大家一定要清楚,移植是基于操作系统的。但是这个时候,我们需要注意一点:基于各种操作系统平台不同,应用程序在二级制级别是不能直接移植的。我们只能在代码层去思考可移植问题,在API层面上由于各个操作系统的命名规范、系统调用等自身原因,在API层面上实现可移植也是不大可能的。那怎么才能实现可移植呢?
      
我们首先来看看现在主流的Windows和Linux平台下代码可移植性。有什么办法解决这个问题呢?答案是:在各个平台之间,基于大部分需求抽象出一个中间层。在中间层中,中间层用了屏蔽底层细节,在我们程序员看来C言语库就是这样一个中间层的作用。在各个平台下,我们默认C标准库中的函数都是一样的,这样基本可以实现可移植。但是对于C库本身而言,在各种操作系统平台下其内部实现是完全不同的,也就是说C库封装了操作系统API在其内部的实现细节。
      
因此,C语言提供了我们在代码级的可移植性,即这种可移植是通过C语言这个中间层来完成的。
      
当然,大家都可以看出上面的可移植是有条件的,C语言本身不能实现完全的可移植,为什么呢?因为,在我们程序中,我们经常会调用系统API,由于这些API在C语言中没有对其封装,所以我们只能用使用其原始的API,对于原始的API在各个操作系统中他们命名不同,就不能跨平台移植。所以,我们要写出完完全全的跨平台的程序,还是需要其他的一些手段。例如在我们的代码中下功夫。以下代码可以帮助我们实现各平台之间的可移植:
#ifndef _WINDOWS_        CreateThread();      //windows下线程的创建
#else        Pthread_create();    //Linux下线程的创建 #endif
对于头文件,也使用同样的预编译宏来实现。如: #ifndef _WINDOWS_       
#include <windows.h> #else        #include <thread.h>
#endif
这样就可以实现代码的可移植了。在编译的时候只要通过#define就可以选择在那个平台下完成程序的编译。
      
综上所述,我们都是将C,C++等各种语言当作中间层,以实现其一定程度上的可移植。如今,语言的跨平台的程序都是以这样的方式实现的。但是在不同的平台下,仍需要重新编译。  

1、gcc(gnu collect
compiler)是一组编译工具的总称。它主要完成的工作任务是“预处理”和“编译”,以及提供了与编译器紧密相关的运行库的支持,如libgcc_s.so、libstdc++.so等。

清单 1. 设置预编译选项示例代码如下:
// Procedure.cpp 
 void SomeFunction() 
 { 
    //Common code for all linux 
    ...... 
    ...... 
 #ifdef RHEL 
    SpecialCaseForRHEL(); 
 #endif 

 #ifdef SUSE 
    SpecialCaseForSUSE(); 
 #endif 

 #ifdef UBUNTU 
    SpecialCaseForUBUNTU(); 
 #endif 

    //Common code for all linux 
    ...... 
    ...... 

 #ifdef RHEL 
    SpecialCase2ForRHEL(); 
 #endif 

 #ifdef SUSE 
    SpecialCase2ForSUSE(); 
 #endif 

 #ifdef UBUNTU 
    SpecialCase2ForUBUNTU(); 
 #endif 

    //Common code for all linux 
 ...... 
 ...... 
 }

开发人员可以通过设置 makefile 宏参数或者直接设置 gcc
参数来控制实际编译内容。

例如:

gcc -D RHEL Procedure.cpp -o Result.so -lstdc++   // Use RHEL marco

SpecialCaseForRHEL(),SpecialCaseForSUSE(),SpecialCaseForUBUNTU()
分别在该库 (Results.so) 的其他文件中予以实现。

本文出自 “HelloWorld”
博客,请务必保留此出处

Linux系统下的Gcc(GNU C
Compiler)是GNU推出的功能强大、性能优越的多平台编译器,是GNU的代表作品之一。gcc是可以在多种硬体平台上编译出可执行程序的超级编译器,其执行效率与一般的编译器相比平均效率要高20%~30%。 
Gcc
编译器能将C、C++语言源程序、汇程式化序和目标程序编译、连接成可执行文件,如果没有给出可执行文件的名字,gcc将生成一个名为a.out的文件。
在Linux系统中,可执行文件没有统一的后缀,系统从文件的属性来区分可执行文件和不可执行文件。而gcc则通过后缀来区别输入文件的类别,下面我们来
介绍gcc所遵循的部分约定规则。 
.c为后缀的文件,C语言源代码文件; 
.a为后缀的文件,是由目标文件构成的档案库文件; 
.C,.cc或.cxx 为后缀的文件,是C++源代码文件; 
.h为后缀的文件,是程序所包含的头文件; 
.i 为后缀的文件,是已经预处理过的C源代码文件; 
.ii为后缀的文件,是已经预处理过的C++源代码文件; 
.m为后缀的文件,是Objective-C源代码文件; 
.o为后缀的文件,是编译后的目标文件; 
.s为后缀的文件,是汇编语言源代码文件; 
.S为后缀的文件,是经过预编译的汇编语言源代码文件。 
Gcc的执行过程 
虽然我们称Gcc是C语言的编译器,但使用gcc由C语言源代码文件生成可执行文件的过程不仅仅是编译的过程,而是要经历四个相互关联的步骤∶预处理(也称
预编译,Preprocessing)、编译(Compilation)、汇编(Assembly)和连接(Linking)。 
命令gcc首先
调用cpp进行预处理,在预处理过程中,对源代码文件中的文件包含(include)、预编译语句(如宏定义define等)进行分析。接着调用cc1进
行编译,这个阶段根据输入文件生成以.o为后缀的目标文件。汇编过程是针对汇编语言的步骤,调用as进行工作,一般来讲,.S为后缀的汇编语言源代码文件
和汇编、.s为后缀的汇编语言文件经过预编译和汇编之后都生成以.o为后缀的目标文件。当所有的目标文件都生成之后,gcc就调用ld来完成最后的关键性
工作,这个阶段就是连接。在连接阶段,所有的目标文件被安排在可执行程序中的恰当的位置,同时,该程序所调用到的库函数也从各自所在的档案库中连到合适的
地方。

图 1. 清单 1 代码的结构图

图片 1

 

带来的问题

  1. SomeFunction()
    函数代码冗余,格式混乱。本例仅涉及三个预编译选项,但实际情况中由于
    Linux
    版本众多并且可能涉及操作系统位数的问题,增加对新系统的支持会导致预编译选项不断增多,造成
    SomeFunction() 函数结构十分混乱。
  2. 新增其他平台相关接口(例如:增加
    SpecialCase3ForRHEL(),SpecialCase3ForSUSE(),SpecialCase3ForUBUNTU),会成倍增加代码中预编译宏的数量。
  3. 破坏了接口平台无关性的原则。SpecialCaseForRHEL(),SpecialCaseForSUSE(),SpecialCaseForUBUNTU()
    只是同一功能各个平台的不同实现,属于封装内容,不应该分开暴露给调用者。

可见,简单利用预编译宏来解决平台相关代码产生的问题不是一个好的方法,并没有解决本文开始提出的两个问题。后文将通过三个方案依次解决这些问题。

2、binutils提供了一系列用来创建、管理和维护二进制目标文件的工具程序,如汇编(as)、连接(ld)、静态库归档(ar)、反汇编
(objdump)、elf结构分析工具(readelf)、无效调试信息和符号的工具(strip)等。通常,binutils与gcc是紧密相集成
的,没有binutils的话,gcc是不能正常工作的。

解决方案 1:根据接口平台无关性原则进行优化

实质上,SpecialCaseForRHEL(),SpecialCaseForSUSE(),SpecialCaseForUBUNTU()
只是同一功能在不同平台上的实现,SpecialCase2ForRHEL(),SpecialCase2ForSUSE(),SpecialCase2ForUBUNTU()
亦如此。对于调用者,应该遵循接口平台无关性的原则,使用统一的接口进行调用,这样才能简化代码,使代码易于维护。

3、glibc是gnu发布的libc库,也即c运行库。glibc是linux系统中最底层的api(应用程序开发接口),几乎其它任何的运行库
都会倚赖于glibc。glibc除了封装linux操作系统所提供的系统服务外,它本身也提供了许多其它一些必要功能服务的实现,主要的如下:
 (1)string,字符串处理
 (2)signal,信号处理
 (3)dlfcn,管理共享库的动态加载
 (4)direct,文件目录操作
 (5)elf,共享库的动态加载器,也即interpreter
 (6)iconv,不同字符集的编码转换
 (7)inet,socket接口的实现
 (8)intl,国际化,也即gettext的实现
 (9)io
 (10)linuxthreads
 (11)locale,本地化
 (12)login,虚拟终端设备的管理,及系统的安全访问
 (13)malloc,动态内存的分配与管理
 (14)nis
 (15)stdlib,其它基本功能

清单 2. 解决方案 1 示例代码如下:
// Procedure.cpp 
 void SomeFunction() 
 { 
    //Common code for all linux 
    ...... 
    ...... 
    SpecialCase(); 

    //Common code for all linux 
    ...... 
    ...... 

    SpecialCase2(); 

    //Common code for all linux 
    ...... 
    ...... 
 } 

 void SpecialCase() 
 { 
    //Common code for all linux 
    ...... 
    ...... 
 #ifdef RHEL 
    SpecialCaseForRHEL(); 
 #endif 

 #ifdef SUSE 
    SpecialCaseForSUSE(); 
 #endif 

 #ifdef UBUNTU 
    SpecialCaseForUBUNTU(); 
 #endif 

    //Common code for all linux 
    ...... 
    ...... 
 } 

 void Special2Case() 
 { 
    //Common code for all linux 
    ...... 
    ...... 
 #ifdef RHEL 
    SpecialCase2ForRHEL(); 
 #endif 

 #ifdef SUSE 
    SpecialCase2ForSUSE(); 
 #endif 

 #ifdef UBUNTU 
    SpecialCase2ForUBUNTU(); 
 #endif 

    //Common code for all linux 
    ...... 
    ...... 
 }

 

此方案的优点:

遵循了接口平台无关性原则,同样的功能只提供一个接口,每个平台的实现属于实现细节,封装在接口内部。此方案提供了一定的封装性,简化了调用者的操作。

3、glibc和libc都是Linux下的C函数库,那么到底有什么区别呢?
见到Linux下好多的库函数,曾经令我困惑,其实他们是有章可循的。
libc是Linux下的ANSI C的函数库;
glibc是Linux下的GUN C函数库;
ANSI C和GNU C有什么区别呢?
ANSI C是基本的C语言函数库,包含了C语言最基本的库函数。这个库可以根据
头文件划分为 15 个部分,其中包括:字符类型 (<ctype.h>)、错误码
(<errno.h>)、 浮点常数 (<float.h>)、数学常数
(<math.h>)、标准定义 (<stddef.h>)、 标准 I/O
(<stdio.h>)、工具函数 (<stdlib.h>)、字符串操作
(<string.h>)、 时间和日期 (<time.h>)、可变参数表
(<stdarg.h>)、信号 (<signal.h>)、 非局部跳转
(<setjmp.h>)、本地信息 (<local.h>)、程序断言
(<assert.h>) 等等。这在其他的C语言的IDE中都是有的。
而GNU
C函数库是一种类似于第三方插件的东西,由于Linux是用C语言写的,所以Linux的一些操作是用C语言实现的,所以GNU组织开发了一个C语言的库
用于我们更好的利用C语言开发基于Linux操作系统的程序。其实我们可以把它理解为类似于Qt是一个C++的第三方函数库一样。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图