本文来自：http://blog.csdn.net/yui/article/details/5669922

函数说明

函数使用

众所周知，C程序的主函数有两个参数，其中，第一个参数是整型，可以获得包括程序名字的参数个数，第二个参数是字符数组指针或字符指针的指针，可以按顺序获得命令行上各个字符串参数。其原形是：

int main(int argc, char *argv[]);

或者

int main(int argc, char **argv);

如果有一个解析CDR的程序，名叫destroy，负责将一个二进制格式的CDR文件转换为文本文件，输出的文本的样式由另外一个描述文件定义，那么，命令行要求输入的参数就有三个：CDR文件名、输出文件名和描述文件名。其中，前两个参数是必须输入的，第三个的描述文件名可以不输入，程序会自动采用默认的输出样式。很自然，主函数的三个参数就应该这样排列：

./destroy cdr cdr.txt [cdr.desc]

这样做在一般情况下不会有太大问题，问题来源于扩展性的需求。如果有一天，用户要求解析程序能够按关键字解析，只有含有关键字的CDR才能够输出。解决方法很简单，只要在参数列表的最后，加上它就可以了。不过，这样就使得原本可选的描述文件名变为必须输入：

./destroy cdr cdr.txt cdr.desc [keyword]

因为不改的话，你就不知道，第三个参数究竟是描述文件名，还是关键字。现在还算好办，如果以后陆续有增加参数的需求，关键字也变成必须输入了，这个时候，如果要查找全部CDR，你还得定义一个“特殊的关键字”，告诉程序，把数据统统给我捞出来……

有鉴于此，在Unix/linux的正式的项目上，程序员通常会使用getopt()或者getopt_long()来获得输入的参数。两者的一个区别在于getopt()只支持短格式参数，而getopt_long()既支持短格式参数，又支持长格式参数。

短格式：./destroy -f cdr -o cdr.txt -c cdr.desc -k 123456

长格式：./destroy --file cdr --output cdr.txt --config cdr.desc --keyword 123456

引入了getopt()和getopt_long()的项目，设计者可以按需要，方便地增加参数，或者随意地放置参数的先后次序，只需要在程序中判断，哪些参数是必须的就可以了。关于这两个函数的用法，大家可以上网搜索一下，不再累述。附件destroy_linux.c给出了在Linux下使用getopt_long()的实例。

另外一个区别是，getopt()几乎通用于所有类Unix系统，而getopt_long()只有在GNU的Unix/Linux下才能用。如果把上述程序放到Tru64上编译，就会出现以下错误：

cc -o destroy destroy_linux.c

cc: Error: destroy_linux.c, line 24: In the initializer for long_opts, an array's element type is incomplete, which precludes its initialization. (incompelinit)

                {"help", no_argument, NULL, 'h'},

----------------^

所以，如果一定要在Tru64等非GNU的OS上做到长格式的效果，除了自己另起炉灶之外，基本上只好借助一些跨平台的开源项目了。附件里的getopt_long.c和getopt.h是从opensolaris的网站上抄下来的，是包含在sg3_utils软件包中的程序。sg3_utils具体是什么，我也不知道，据说是一个Linux的开发包，用来直接使用SCSI命令集访问设备。（sg3_utils is a package of utilities for accessing devices that use SCSI command sets.）反正拿来能用就是了！

拿过来后，把他们放到与destroy_linux.c同一目录下，只需要把destroy_linux.c的头文件改一个地方，#include <getopt.h>改为#include “getopt.h”，就能够编译运行了。而且，这样改好后，不仅在Tru64上能运行，在Linux、SunOS上也能运行。

Linux下编译

-bash-3.2$ gcc -o destroy destroy.c getopt_long.c

短格式，全部输入

-bash-3.2$ ./destroy -f aaa -o aaa.txt -c ccc -k 222

Parameters got: file_name = aaa, output_name = aaa.txt, config_name = ccc, keyword = 222

前两个长格式，后两个短格式

-bash-3.2$ ./destroy --file aaa --output aaa.txt -c ccc -k 222

Parameters got: file_name = aaa, output_name = aaa.txt, config_name = ccc, keyword = 222

漏掉一个必须输入的参数会报错

-bash-3.2$ ./destroy -output aaa.txt

Error: file name must be specified

次序随意，长短混用

-bash-3.2$ ./destroy -c ccc -o aaa.txt -k 222 --file aaa

Parameters got: file_name = aaa, output_name = aaa.txt, config_name = ccc, keyword = 222

题外话，#include <filename.h>与#include “filename.h”有什么区别，是面试C程序员经常问到的一个问题。答案大家都知道了，#include <filename.h>，编译器从标准库路径搜索filename.h，而#include “filename.h”，编译器从用户的工作路径搜索filename.h。

此外，网上也有人说从glibc（http://sourceware.org/glibc/）上把getopt.h、getopt.c和getoptl.c拿过来也能够用。我也试过，但是不清楚什么原因不成功。

在这个小实验的过程中，还发现了C语言在各个OS下的一些细小差异，比如destroy.c里，79行到82行：

// if not setting default, Linux OK, but SunOS core dump

if ( !config_name ) config_name = "(null)";

if ( !keyword ) keyword = "(null)";

printf("Parameters got: file_name = %s, output_name = %s, config_name = %s, keyword = %s/n", file_name, output_name, config_name, keyword);

如果在81行和82行不设置空指针的默认值，Linux和Tru64都会自动帮你转换而避免运行时错误，但是SunOS不会，它会死给你看。

./destroy -f aaa -o aaa.txt

Segmentation Fault (core dumped)

再比如第62行的abort()在头文件stdlib.h中定义，如果不包含此文件，SunOS与Tru64编译都没问题，Linux编译时会警告：

warning: incompatible implicit declaration of built-in function abort

由此看来，虽然C也公认是可移植性比较好的语言，但是在跨平台的项目中，也应该注意这些微小的差别。

转自：http://blog.csdn.net/lanmanck/article/details/11999345