Unix Linux下C C++开发技术概览

Unix/Linux下C/C++开发技术概览1.平台差异简介Windows和Unix是当前两大主流操作系统平台，基于C/C++的开发人员经常会面临这两个平台之间的移植的问题。Unix作为一个开发式的系统，其下有出现了很多个分支，包括Sun的Solaris、IBM的AIX、HPUnix、SCOUnix、FreeBSD、苹果的MACOS以及开源的Linux等。对于这些Unix的分支操作系统，其实现又有很大的差别，因此开发人员又要针对这些不同的系统进行移植。本文的目的就是介绍一下Windows平台和Unix平台之间的差别，并简单介绍一下不同Unix分支操作系统之间的差别，在移植开发过程中的一些注意事项，同时简要介绍一下Unix下开发的一般流程和常用的开发调试工具。关于平台之间的差异，主要是Windows平台和Unix平台之间的差异，这里着重介绍一下这两个平台在C/C++开发中存在的差异，其间会穿插介绍一些Unix不同分支之间的差异。1.1语言特性的差异语言特性的差异，指的是不同操作系统平台中，实现C++/C时的一些细微的差异，忽略这些差异可能会带来一些特别隐蔽的错误。而且可能是致命的错误。所以，了解语言特性的差异，对于在Unix移植来说非常重要。如果考虑系统多多个平台支持，就必须了解在不同平台下语言特性的差异，从开发一开始就把这些因素考虑进去，这样才能最低限度的降低移植的过程中工作量。1.1.1字节顺序的差异字节顺序指的主要是整型变量在内存中的存储方式。在计算机中，数据都是以二进制方式存储的，包括在内存和硬盘中。而计算机又以8位二进制作为一个存储单元。在32位系统中，一个整型的存储需要四个存储单元。也就是说要把一个32位的整数分割成位四段分别进行存储，而每一段的存储位置就是字节顺序的差异。为了清楚的表示每段存储的先后位置，我们用16进制来表示一段的值，下表列出了在Unix系统和Windows系统中整数20000在内存中的情况。十六进制表示0x00004E20Windows内存表示204E0000Unix内存表示00004E20如表中所示，Windows中存储方式和该整数的16进制表示是相反，是一种低位在前高位在后的存储顺序。而Unix下的存储顺序和正常的16进制表示的顺序相同，称为高位在前低位在后的顺序。这种差异带来的问题，主要体现在以下几个方面：网络通信时当Windows和Unix之间发生网络数据传输，传输一个整型数据（如一个数据包的长度）的时候，如果不经处理直接把内存中的数据传输过去，那么在对方看来完全是另一个数据，这样就会造成问题。如Windows下面发送过去一个20000（0x00004E20），在Unix下面收到的数据就会被理解成541982720（0x204E0000），这简直是天壤之别。文件存储和读取时跟网络传输类似，如果在Windows下面把某个整数写到了文件中，然后在Unix下面打开这个文件读取该数据，就会出现跟上面类似的问题。这个问题主要体现在不同平台之间互操作时，在多平台开发过程中，尤其时在网络应用开发的时候，两个平台之间数据交互是非常普遍的，所以这个问题也就显的很普遍。解决这个问题的方法就是交互的双方采用一种相同的数据编码标准，就是数据在传输和存储的时候采用什么方法进行编码，具体的做法有一下几种：1．数字转换成字符传进行交互2．协商一个同意的字节顺序，根据自己平台的字节顺序还原数据3．采用其他标准的编码方式，如ASN1编码跟这个问题类似，32位系统和64位系统的差异也会出现这样的问题，解决方法跟这个问题的解决方法相同。在32位系统和64位系统中，长整型（long）分别用32位和64位表示，这样，在不同系统之间交互的时候必然会出现整型数据表示方式不同的问题。目前大多数Windows系统都是32位的系统，而Unix中很多都是64位的，尤其是大型的服务器，所以这个问题必须引起重视。1.1.2变量的作用域差异在不同的系统下，由于编译器的不同，对变量作用域的实现机制也有所不同，这里以Windows下的VC和Solaris下的CC这两个编译器为例做一个简单的比较说明。在C++的开发过程中，我们经常会有这样的用法：for(inti=0;inum;i++){…}这是一种最常用的for循环的用法，因为其中i主要使用来控制循环，所以一般没有必要拿出来单独进行声明，只是放在for语句中一起声明。这里i、j等简单的变量就成了我们常用的变量，一般不按照编程规范那样为他们命名。就是这种声明方法，在Windows下和Solaris下有了不同的理解，i的作用域不同。我们先把作用域进行划分，如下：{…for(inti=0;inum;i++){II…}……}我们划分出I和II两个作用域，其中作用域II包含在作用域I当中。在Windows下，变量i的作用域是I的整个范围，而Solaris下的i的作用域只是II的范围。其实标准的C++语法应该是Solaris的做法，但是微软在实现的时候没有按照这个标准实现，这就引发了我们讨论的这个问题。由于这个差异，就引发了一些微妙而隐蔽的问题。先看一下下面两端代码。A：for(inti=0;inum;i++){…}…for(i=0;inum;i++){…}B：for(inti=0;inum;i++){…}…for(inti=0;inum;i++){…}代码A在Windows下面可以正常编译，而在Solaris下面确编不过去，提示第二个for循环中变量i没有定义。相反代码B在Solaris下可以正常编译，而在Windows下面编不过去，提示第二个for循环中变量i重复定义。在通常的情况下，我们会按照B的方法书写代码，而在Windows编译是出现错误，然后改成A的那种形式。这样，在Windows下就没有问题了，程序也可以编译过去了，但是到Solaris下时，有会出现问题，这是就不得不把i的声明拿到所有for循环的外面。当i的声明拿到for循环的外面时，真正的问题来了。首先提示一下，这样的一段代码是没有问题的：C：Iinti=0;if(cond){…for(inti=0;inum;i++){…}…}这是一段正确的代码，虽然在外面已经定义了i，但是在for里面重新定义一个i也没有问题，这是C++的语法所允许的（java里面不允许这样做）。但就是因为这种C++语言的灵活机制，引发了问题的产生。问题产生源于程序中出现了A_B那样的代码，然后把i的声明拿到了外面。在后期维护的过程中，又在后面增加了一个循环，但是却是按照C的那种方式增加的，这样就产生了问题。请看如下代码：inti=0;charstr1[10];charstr2[10];strcpy(str1,”hello”);…for(i=0;i20;i++){…}…if(cond){for(inti=0;i10;i++){if(str1[i]==0)break;}memcpy(str2,str1,i);str2[i]=0;}…在上述代码，为了分析方便，我们把整段代码分成I、II和III三个作用域。其中作用域II就是整个if语句，实现的相当于一个strcpy函数的功能。II中的内容就好是我们上面说的后期维护中加入的，当然，实际情况并不像我们例子中这么明前，i的声明可能离我们的if语句很远，所以加入这段代码是不知道上面是否声明了i变量。而且，这段代码编译的时候也不回出错，不管是WindowsIIIIII还是Solaris（单独的一段II中的代码在Solaris下面编不过去）。在Windows下面，这段代码可以正常的运行，不回出现任何问题，因为II中的代码完全是根据Windows下的习惯编写的。但是在Solaris下面，这段代码就会出现内存越界的错误，虽然编译可以正常通过，但是实现的却不是程序员预期的目的。在执行memcpy的时候，那个i其实是外层声明的那个i，值是20，而str2和str1的大小之后10，所以就发生了读写内存越界。而程序员预想的，这个i是for循环算出来的str1字符串的长度，应该是5。要解决这类问题，就得加强编程规范，杜绝这种错误代码的生成。从开始的时候就要意识到可能产生的问题，从而避免问题的发生。1.1.3全局对象的初始化在C++中，初始化对象的时候系统会自动调用构造函数，因此我们习惯在构造函数中做一些初始化的工作，让自动自动为我们调用初始化的操作。其中，有些对象是静态分配的全局对象，就是在任何函数体外声明的对象，如：CMyObjectg_Object;通常情况下，程序启动的时候，系统都会自动调用这个对象的构造函数对这个全局对象进行初始化，但是在某些系统中（SCOUnix），就不想我们期望的那样，也许这是编译器实现的一个bug，但是我们也不能忽视这个问题的存在。对于这种问题，我们可以通过显式创建对象的方法解决，如下：CMyObject*g_pObject=newCMyObject;这样，系统在启动的时候，就会执行newCMyObject来为对象分配空间，同时执行调用对象的构造函数来初始化对象。如果不想使用指针的方式引用该对象（为了安全因素，不想某个函数在程序运行期间把这个指针置空），那么我们可以采用另一种方法，如下：CMyObject&g_Object=*(newCMyObject);这样也可以达到对像创建和初始化的工作。虽然对于我们分配的这个对象没有进行释放操作，但是全局只有这么一次，所以不用担心内存泄漏问题。程序运行结束的时候，操作系统会自动释放掉程序所申请的所有内存，当然也包含这个对象。1.1.4语法检查的差异不同操作系统下面有不同的编译器的实现，不同的编译器对语法要求的程度不同。在Windows下可以正常编译的代码，在Unix下就可能出现语法错误。1.1.2中就是一个典型的例子。另外，还有一些其他方面的语法检查的差异。C是一中很灵活的语言，语法很自由，但是不同的平台下这中自由的程度也不同。WindowsVC、SolarisCC和Linuxgcc实现的都不错，但是有些其他的系统实现的就不是这么灵活，很多写法在他们下面都行不通。具体的记不太清了，在AIX和SCOUnix下面碰到很多这种情况。所以只能在移植的过程中逐渐的发现和改正。但是只要保证采用标准的书写规范，应该可以更少的产生这种错误。有这样一段代码：if(NULL==pVar){…}这是在大多数平台下面很好的一种习惯，可以避免哪种把“==”写成“=”的错误，在编译期间就能发现。但是在SCOUnix下面，这种写法就会引发编译器的一个警告。这个例子能简单的说明一下不同编译器之间存在的差别。1.2操作系统特性的差异不同的操作系统中都存在一些系统的限制，如打开文件句柄数的限制、Socket等待队列的限制、进程和线程堆栈大小的限制等，因此在开发的过程中，必须考虑到这些限制因素对程序的影响。当然，有些限制参数可以适当的调整，这就需要在发布程序的时候加以声明。另外，操作系统的容错性也对程序有影响。下面分别进行讨论。1.2.1文件描述符的限制文件描述符最初是Unix下的一个概念，在Unix系统中，用文件描述符来表示文件、打开的socket连接等，跟Windows下HANDLE的概念类似。文件描述符是一种系统资源，系统对每个进程可以分配的文件描述符数量都有限制。以Solaris为例，默认情况下每个进程可以打开的文件描述符为1024个，系统的硬限制是8192（具体的值跟版本有关），也就是说可以调整到8192。在Unix系统下使用ulimit命令来获得系统的这些限制参数。一般情况下，这都是够用的，但是有一个例外，在32为的Solaris程序中，使用标准输入输出函数（stdio）进行文件的操作，最大的文件描述符不能超过256。比如说用fopen打开文件，出去系统占用的3个文件描述符（stdin、stdout和stderr），程序中只能再同时打开253个文件。如果使用open函数来打开文件，就没有这个限制，但是就不能够使用stdio中的那些函数进行操作了，是程序的通用性和灵活性有所降低。