当前位置: 欧洲杯竞猜 > 服务器运维 > 正文

欧洲杯竞猜:的不一样和维系,平台相关代码的

时间:2020-03-17 01:14来源:服务器运维
本文首先提出平台相关代码造成的两个问题,然后针对这两个问题循序渐进依次提出解决方案,在分析了前两个方案弱点的基础上,最后着重介绍一种基于多种设计模式的Linux 平台相关

本文首先提出平台相关代码造成的两个问题,然后针对这两个问题循序渐进依次提出解决方案,在分析了前两个方案弱点的基础上,最后着重介绍一种基于多种设计模式的 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 的第三方函数库一样。

此方案的缺点:

预编译宏泛滥的问题仍然没有解决,每次新增功能函数,就会成倍增加预编译宏的数量。同样每次增加对已有功能新平台的支持,也会不断增加预编译宏的数量。

可见,此方案部分解决了本文开始提出的两个问题中的一个,但仍有问题需要继续解决。

解决方案 2: 通过分层对进行优化

换一个角度来思考,可以在二进制层面对平台相关代码进行优化。通过对库的结构进行分层来优化,为每个 Linux 平台提供单独的实现库,并且把调用端独立提取出来。如下图所示:

图 2: 方案 2 的结构图

欧洲杯竞猜 2

此方案单独将调用端抽象出来,将每个平台实现端的相关代码提取出来做成一个单独的库(Rhel.so,Suse.so,Ubuntu.so)。SpecialCase() 为同一功能在不同平台的实现,采用相同接口名。底层库需要与 Results.so 库同时发布,也就是说,Redhat 版本发布时需同时打包 Results.so 和 Rhel.so,其他版本亦然。

此方案的优点:

解决了预编译宏泛滥的问题,通过二进制分层可以将代码里的所有预编译选项去掉。遵循了接口平台无关性的原则。

可见,此方案很好地解决了本文开始提出的两个问题。

此方案的缺点:

每次发布 Results.so 的时候,底层库需要伴随一起发布,导致可执行包文件数量成倍增加。而且很多小程序,小工具的发布往往采取单独的二进制文件,不允许有底层库的存在。

解决方案 3: 结合代理模式,桥接模式和单例模式进行优化

现在针对原始问题继续进行优化,摈弃方案 2 采用的分层手法,在单一库的范围内利用 C 多态特性和设计模式进行优化。

目标效果:

  1. 源代码中尽可能减少预编译选项出现的频率,避免因功能扩展和平台支持的增加导致预编译宏数量爆炸。
  2. 完全遵循接口平台无关性的原则。
清单 3. 解决方案 3 调用端示例代码如下:
// Procedure.cpp 
 void SomeFunction() 
 { 
    //Common code for all linux 
    ...... 
    ...... 
    XXHost::instance()->SpecialCase1(); 

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

 XXHost::instance()->SpecialCase2(); 

    //Common code for all linux 
    ...... 
 ...... 
 }
图 3:方案 3 的具体实现类图

欧洲杯竞猜 3

此方案结合改进的代理模式(Proxy),桥接模式(Bridge)和单件模式(Singleton),并利用 C 封装、继承和多态特性予以实现。

IHost 是顶层抽象接口类,声明了实现端需要实现的功能函数以及调用端需要调用的接口函数。

图 3 右半部分派生自 IHost 的各个类为实现端,在实现端,

为每个 Linux 系统单独实现了一个类,相互之间无关联性。该类实现了该操作系统平台相关的功能(SpecialCase1() 和 SpecialCase2()),即实现了平台相关代码。每个实现类采取单件模式。

Init() 和 terminate() 用来初始化和清理操作。Init() 函数首先创建自己(单件模式),其次创建左侧代理类(单件模式,见下段描述),最后将自己的内存地址通过 SetHost() 函数交给左侧代理方。

图 3 左半部分派生自 Host 的各个类为调用端,在调用端,

Host 类做了一层封装,RhelHost 等派生类为实际的代理者(调用者),每个 Host 的派生类分别代表一种需求(调用方),是右侧实现类的一个代理,例如 RhelHost 是 RhelOS 的代理,SuseHost 是 SuseOS 的代理,UbuntuHost 是 UbuntuOS 的代理。每个 Host 的派生类采取单件模式。

Host 类和 HostImp 类之间采用桥接的设计模式,利用 C 多态特性,最后通过 HostImp 类调用实现端类的实现。调用端的调用过程如下:

  1. 通过 RhelHost 的指针调用 SpecialCase(),由于 RhelHost::SpecialCase() 没有覆盖基类虚函数的实现,实际调用的是 Host::SpecialCase()。
  2. Host 的所有调用被桥接到 HostImp 对应的函数。
  3. 由 HostImp 类调用确定的实现端的某一个对象的对应实现函数(HostImp 类的 SetHost() 函数记录了右侧类的对象内存地址)。

清单 4. 解决方案 3 框架主要源代码如下:

// Host.h 
 class IHost 
 { 
 public: 
    virtual void SpecialCase1() = 0; 
    virtual void SpecialCase2() = 0; 
 }; 

 class Host : public IHost 
 { 
 public: 
    virtual ~Host() {}; 
    void setHost(IHost* pHost) 
    { 
        m_pImp->setHost(pHost); 
    } 
    virtual void SpecialCase1() 
    { 
        m_pImp->SpecialCase1(); 
    }; 
    virtual void SpecialCase2() 
    { 
        m_pImp->SpecialCase2(); 
    }; 

 protected: 
    Host(HostImp * pImp); 

 private: 
    HostImp* m_pImp; 
    friend class HostImp; 
 }; 

 class RhelHost : public Host 
 { 
 public: 
    static RhelHost* instance(); 
 private: 
    RhelHost(HostImp* pImp); 
 }; 

 RhelHost * RhelHost::instance() 
 { 
    static RhelHost * pThis = new RhelHost (new HostImp()); 
    return pThis; 
 } 

 RhelHost:: RhelHost (HostImp* pImp) 
 : Host(pImp) 
 { 
 } 

 class RhelOS : public IHost 
 { 
 public: 
    static void init() 
    { 
        static RhelOS me; 
        RhelHost::instance()->setHost(&me); 
    } 
    static void term() 
    { 
        RhelHost::instance()->setHost(NULL); 
    } 
 private: 
    virtual void SpecialCase1() 
    { 
        /* Real Operation */ 
    }; 
    virtual void SpecialCase2() 
    { 
        /* Real Operation */ 
    }; 

 }; 

 // HostImp.h 
 class HostImp : public IHost 
 { 
 private: 
    HostImp(const HostImp&); 

 public: 
    HostImp(); 
    virtual ~HostImp() {}; 
    void setHost(IHost* pHost) 
    { 
        m_pHost = pHost; 
    }; 
    virtual void SpecialCase1() 
    { 
        if(m_pHost != NULL) 
            m_pHost->SpecialCase1() 
    } 
    virtual void SpecialCase2() 
    { 
        if(m_pHost != NULL) 
            m_pHost->SpecialCase2() 
    } 

 private: 
    IHost* m_pHost; 
 };

此方案的优点:

  1. 遵循接口平台无关性原则。此方案将各平台通用接口提升到最高的抽象层,易于理解和修改。
  2. 最大限度地降低预编译选项在源代码中的使用,实际上,本例中只需要在一处使用预编译宏,示例代码如下:
void Init() 
 { 
 #ifdef RHEL 
    RhelOS::init(); 
 #endif 

 #ifdef SUSE 
    SuseOS::init(); 
 #endif 

 #ifdef UBUNTU 
    UbuntuOS::init(); 
 #endif 
 }
  1. 源代码其他地方不需要添加预编译宏。
  2. 实现端和调用端都通过类的形式进行封装,而且实现端类和调用端类都可以自己单独扩展,完成一些各自需要完成的任务,所要保持一致的只是接口层函数。扩展性和封装性很好。

由此可见,此方案很好地解决了本文开始提出的两个问题,而且代码结构清晰,可维护型好。

接下来对上述源代码继续进行优化。上例 SuseHost/UbuntuHost/SUSEOS/UBUNTUOS 等类的实现被略去,实际上这些类的实现与 RhelHost 和 RHELOS 相似,可以利用宏来进一步优化框架代码结构。

清单 5. 解决方案 3 框架主要源代码优化:
#define HOST_DECLARE(name)  
 class ##nameHost : public Host  
 {  
 public:  
    static ##nameHost* instance();  
 private:  
    ##nameHost(HostImp* pImp);  
 }; 

 #define HOST_DEFINE(name)  
 ##nameHost* ##nameHost::instance()  
 {  
    static ##nameHost* pThis = new ##nameHost(new HostImp());  
    return pThis;  
 }  
 ##nameHost::##nameHost(HostImp* pImp)  
 : Host(pImp)  
 {  
 } 

 #define HOST_IMPLEMENTATION(name)  
 class ##name##OS : public IHost  
 {  
 public:  
    static void init()  
    {  
        static ##name##OS me;  
        ##nameHost::instance()->setHost(&me);  
    }  
    static void term()  
    {  
        ##nameHost::instance()->setHost(NULL);  
    }  
 private:  
 virtual void SpecialCase1();  
    virtual void SpecialCase2();  
 };

使用三个宏来处理相似代码。至此,优化完成。从源代码角度来分析,作为实现端的开发人员,只需要三步就可以完成操作:

  1. 调用 init() 函数;
  2. 使用 #define HOST_IMPLEMENTATION(name);    例如:#define HOST_IMPLEMENTATION(DEBIAN)
  3. 实现 DEBIAN::SpecialCase1() 和 DEBIAN::SpecialCase2()。    作为调用端的开发人员,也只需要三步就可以完成操作:
  4. 使用 #define HOST_DECLARE(name) 进行声明;    例如 : #define HOST_DECLARE(DEBIAN)
  5. 使用 #define HOST_DEFINE(name) 进行定义;    例如: #define HOST_DEFINE (DEBIAN)
  6. 调用接口。    例如: DEBIANHost::instance()->SpecialCase1();DEBIANHost::instance()->SpecialCase2();

可见,优化后方案的代码清晰,不失为一个良好的平台相关代码的解决方案。

由于调用端和实现端往往需要传递参数,可以通过 SpecialCase1() 函数的参数来传递参数,同样的这个参数类可以通过桥接的方式予以实现,本文不再详述,读者可以自己尝试。

对方案 3 的扩展

扩展 1:对单一操作系统多对多的扩展

对于方案 3 的实现,也许有读者会问,调用端只需要 Host 类不需要其派生类即可完成方案 3 中的功能,的确如此,因为方案 3 中的代理类一直是一对一的关系,即 RhelHost 代理 RhelOS,Redhat 下只存在这一对一的关系。但是实际情况下,单一系统下很可能存在多对多的关系。

例如,在单一操作系统中,可能需要同时实现多种风格的窗口。实际上,变成了多对多的代理关系。

图 4:单一操作系统不同 c 风格窗口的实现类图

欧洲杯竞猜 4

Style1Host 代理 Style1Dialog,Style2Host 代理 Style2Dialog,Style3Host 代理 Style3Dialog,三个窗口同时并存,也就是说左侧三个实现类的实例和右侧三个代理类的实例同时存在。可见,方案 3 的设计模式扩展性良好,实现端和调用端都可以在遵循接口不变性的情况下单独扩展自己的功能。

扩展 2:对多操作系统的扩展

方案 3 不仅可以针对 Linux 平台相关代码进行处理,还可以扩展到其他诸多场合。例如,现在的程序库往往需要针对多个操作系统,包括 Windows, Linux, Mac。每个操作系统往往使用不同的 GUI 库,这样在实现窗口操作的时候必然涉及到平台相关代码。同样可以用方案 3 予以实现。

图 5:多操作系统的实现类图

欧洲杯竞猜 5

总结

本文开始提出平台相关代码造成的两个问题,接着循序渐进提出解决方案。在分析了常用的设置预编译选项方法的利弊的基础上,提出了一种新的利用 C 多态特性,结合使用代理模式,桥接模式和单件模式处理平台相关代码的方案,并对这一方案予以扩展,给读者提供了一种新的高效的处理平台相关代码的方法。

编辑:服务器运维 本文来源:欧洲杯竞猜:的不一样和维系,平台相关代码的

关键词: 欧洲杯竞猜