C++博客-OwnWaterloo

C与C++的细微区别——省略形式参数名

OwnWaterloo — Sun, 26 Apr 2009 07:01:00 GMT

一、C与C++的细微区别

在函数声明中：
无论是C还是在C++，都可以省略形式参数名。
但是，通常都不建议省略形式参数名。

在函数定义中：
1. 当需要使用形式参数的时候，显然，必须给形式参数命名。

2. 当不需要使用形式参数的时候，C与C++有微小差异：
—— C不能省略形式参数名，即使不使用。
—— C++可以省略形式参数名，如果不使用。
—— 并且在C++中，如果给不使用的形式参数命名，可能会得到一个警告。

二、示例：

#include <stdio.h>

void greeting_omit(const char* name);
void greeting_unuse(const char* name);
void greeting_nowarning(const char* name);

int main(void) {
    greeting_omit("");
    greeting_unuse("");
    greeting_nowarning("");
    (void)getchar();
    return 0;
}

三、三个函数分别实现如下：

三、1

void greeting_omit(const char* ) {
printf("hello world\n");
}

——在C中是错误：
1. msvc :
error C2055: expected formal parameter list, not a type list
error C2055: 应输入形参表，而不是类型表

2. gcc : （报错更清晰一些）
error: parameter name omitted
错误：省略参数名

——在C++中正确，且无警告。

三、2

void greeting_unuse(const char* name) {
printf("hello Cherrie\n");
}

在C和C++中都正确，但可能得到一个警告：
1. msvc :
warning C4100: 'name' : unreferenced formal parameter
warning C4100: “name”: 未引用的形参

2. gcc :
warning: unused parameter 'name'
警告：未使用的参数‘name’

在gcc中，打开这个警告的选项是-Wunused-parameter。
该选项包含在-Wall中。

三、3

void greeting_nowarning(const char* name) {
(void)name;
printf("hello OwnWaterloo\n");
}

在C和C++中都正确，并且无警告。

相关链接：

——示例代码
http://immature.googlecode.com/svn/trunk/iMmature/sample/omit_parameter_name

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。

转载请注明：
文章作者 - OwnWaterloo
发表时间 - 2009年04月26日
原文链接 - http://www.cppblog.com/ownwaterloo/archive/2009/04/26/omit_parameter_name.html

OwnWaterloo 2009-04-26 15:01 发表评论

main函数中省略返回语句

OwnWaterloo — Sun, 26 Apr 2009 06:37:00 GMT

一、依据

C++标准规定：main函数可以省略返回语句，等效于返回0。

5. A return statement in main has the effect of leaving the main function (destroying any objects with automatic storage duration) and calling exit with the return value as the argument.
If control reaches the end of main without encountering a return statement, the effect is that of executing
return 0;

——ISO C++03 3.6.1 Main function p44/72
——ISO C++98 3.6.1 Main function p43/69

注意：
1. main函数的返回类型是int，不是void或者其他类型。
2. 该规则仅仅对main函数适用。
3. 对其他函数，如果省略返回值，将得到一个警告。
4. 应该避免3的情况。

二、示例

二、1. 一个合法的最小化的完整C++程序如下：

int main() {}

二、2. 省略的确切含义

同时，标准中的用语是很考究的：
“当控制到达main结束处时没有遇到return语句，效果与返回0相同”。

即是说，标准规定的是“对省略return的分支，认为返回0”。
同时，标准也允许其他分支含有返回语句。
如下：

int main(int argc,char* []) {
    switch (argc)
    {
    case 1:
        // error, should passing argument
        return -1;
        // parse arguments
    default:
    case 3: // parser argv[2]
    case 2: // parser argv[1]
        ;
    }
    // do some work
    // control reaches here
}

没有输入命令行参数时，返回一个错误。
其他情况，当控制达到main的结尾处时，效果同return 0;

二、3. 对于其他函数，没有这种“优待”
如：

int not_main(int argc) {
    if (argc<=1)
        return -1;
}
int main(int argc,char* []) {
    return not_main(argc);
}

not_main无疑将得到一个警告。
程序在没有输入命令行参数时的返回值将无法预知。

三、验证

三、1. ERRORLEVEL

windows下，可以通过 %ERRORLEVEL% 查询上一次程序返回值。

结果与判断相吻合：
1. minimalist有确定的返回值0
2. omit_return_in_main有确定的返回值-1或0
3. 对omit_return_in_other
3.1 有命令行参数时，返回值确定为0。
3.2 无命令行参数时，返回值无法预知。

三、2 汇编代码

更严谨的验证方法是查看汇编代码。

可以看到，在minimalist与omit_return_in_main的main函数中都有将eax置0的代码。
在omit_return_in_other中的not_main函数中，没有这样的代码。

四、例外

VC6在这点上与标准不符。

        四、1. 对omit_return_in_main，它给出的警告：

warning C4715: 'main' : not all control paths return a value

说明它在这点上与标准不符。
显然，在有命令行参数的时候，程序结果无法预知。

        四、2. 对minimalist，它给出的警告很搞笑：

warning C4508: 'main' : function should return a value; 'void' return type assumed

暴露出它另一个与标准不符的地方——main返回void。
显然，任何情况下，程序结果都无法预知。

        四、3. 对omit_return_in_other，是程序员的错误。

五、实践

不知道为什么C++标准在这里开一个“后门”。
——C++在许多地方都是很严谨的。

在实际应用中，尽量不要采用这一特性，因为：
1. 旧编译器不支持
2. C不支持——如果希望main能同时按C语言编译的话

对于演示用的C++代码，与主题无关的代码行能省则省，则可以使用这一特性。
比如：C++标准中的示例代码几乎都采用了这一特性。
由此可得出，C++标准在这里开后门的原因是——让C++标准更薄^_^

相关链接：

——示例代码
http://immature.googlecode.com/svn/trunk/iMmature/sample/omit_return_in_main

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。

转载请注明：
文章作者 - OwnWaterloo
发表时间 - 2009年04月26日
原文链接 - http://www.cppblog.com/ownwaterloo/archive/2009/04/26/omit_return_in_main.html

OwnWaterloo 2009-04-26 14:37 发表评论

可变长参数列表误区与陷阱——va_arg不可接受的类型

OwnWaterloo — Tue, 21 Apr 2009 15:41:00 GMT

实现一个有可变长参数列表函数的时候，会使用到stdarg.h（这里不讨论varargs.h）中提供的宏。

例如，我们要实现一个简易的my_printf：
1. 它只返回void，不记录输出的字符数目
2. 它只接受"%d"按整数输出、"%c"按字符输出、"%%"输出'%'本身
如下：

1 #include <stdarg.h>
2
3 void my_printf(const char* fmt, ... )
4 {
5     va_list ap;
6     va_start(ap,fmt); /* 用最后一个具有参数的类型的参数去初始化ap */
7     for (;*fmt;++fmt)
8     {
9         /* 如果不是控制字符 */
10         if (*fmt!='%')
11         {
12             putchar(*fmt); /* 直接输出 */
13             continue;
14         }
15         /* 如果是控制字符，查看下一字符 */
16         ++fmt;
17         if ('\0'==*fmt) /* 如果是结束符 */
18         {
19             assert(0);  /* 这是一个错误 */
20             break;
21         }
22         switch (*fmt)
23         {
24         case '%': /* 连续2个'%'输出1个'%' */
25             putchar('%');
26             break;
27         case 'd': /* 按照int输出 */
28             {
29                 /* 下一个参数是int，取出 */
30                 int i = va_arg(ap,int);
31                 printf("%d",i);
32             }
33             break;
34         case 'c': /* 按照字符输出 */
35             {
36                 /** 但是，下一个参数是char吗*/
37                 /*  可以这样取出吗？ */
38                 char c = va_arg(ap,char);
39                 printf("%c",c);
40             }
41             break;
43         }
44     }
45     va_end(ap);  /* 释放ap—— 必须！ 见相关链接*/
46 }

这与《C++程序设计语言》中的一道练习题很类似。
——需要支持"%c"控制符

在《C++程序设计语言-题解》中，给出了一个答案（中文p65页）。
但是， 如同上面的代码一样，它们都是错误的！

简单的说，我们用va_arg(ap,type)取出一个参数的时候，
type绝对不能为以下类型：
——char、signed char、unsigned char
——short、unsigned short
——signed short、short int、signed short int、unsigned short int
——float

一个简单的理由是：
——调用者绝对不会向my_printf传递以上类型的实际参数。

在C语言中，调用一个不带原型声明的函数时：
调用者会对每个参数执行“默认实际参数提升(default argument promotions)”。

同时，对可变长参数列表超出最后一个有类型声明的形式参数之后的每一个实际参数，也将执行上述提升工作。
提升工作如下：
——float类型的实际参数将提升到double
——char、short和相应的signed、unsigned类型的实际参数提升到int
——如果int不能存储原值，则提升到unsigned int

然后，调用者将提升后的参数传递给被调用者。
所以，my_printf是绝对无法接收到上述类型的实际参数的。

上面的代码的38与39行，应该改为：

int c = va_arg(ap,int);
printf("%c",c);

同理，如果需要使用short和float，也应该这样：

short s = (short)va_arg(ap,int);
float f = (float)va_arg(ap,double);

这也是printf族函数没有用于short和float的控制符的原因。

附录：

在《C语言程序设计》对可变长参数列表的相关章节中，并没有提到这个陷阱。
但是有提到默认实际参数提升的规则：

在没有函数原型的情况下，char与short类型都将被转换为int类型，float类型将被转换为double类型。
                ——《C语言程序设计》第2版 2.7 类型转换 p36

在其他一些书籍中，也有提到这个规则：

事情很清楚，如果一个参数没有声明，编译器就没有信息去对它执行标准的类型检查和转换。
在这种情况下，一个char或short将作为int传递，float将作为double传递。
这些做未必是程序员所期望的。
脚注：这些都是由C语言继承来的标准提升。
对于由省略号表示的参数，其实际参数在传递之前总执行这些提升（如果它们属于需要提升的类型），将提升后的值传递给有关的函数。——译者注
                ——《C++程序设计语言》第3版-特别版 7.6 p138

…… float类型的参数会自动转换为double类型，short或char类型的参数会自动转换为int类型 ……
                ——《C陷阱与缺陷》 4.4 形参、实参与返回值 p73

这里有一个陷阱需要避免：
va_arg宏的第2个参数不能被指定为char、short或者float类型。
因为char和short类型的参数会被转换为int类型，而float类型的参数会被转换为double类型 ……
例如，这样写肯定是不对的：
c = va_arg(ap,char);
因为我们无法传递一个char类型参数，如果传递了，它将会被自动转化为int类型。上面的式子应该写成：
c = va_arg(ap,int);
                ——《C陷阱与缺陷》p164

2009/05/07 修改：
printf函数族有用于short的控制符“h”。
见：http://www.cplusplus.com/reference/clibrary/cstdio/printf/

相关链接：

——《可变长参数列表误区与陷阱——va_end是必须的吗？》
http://www.cppblog.com/ownwaterloo/archive/2009/04/21/is_va_end_necessary.html

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。

转载请注明：
文章作者 - OwnWaterloo
发表时间 - 2009年04月21日
原文链接 - http://www.cppblog.com/ownwaterloo/archive/2009/04/21/unacceptable_type_in_va_arg.html

OwnWaterloo 2009-04-21 23:41 发表评论

可变长参数列表误区与陷阱——va_end是必须的吗？

OwnWaterloo — Tue, 21 Apr 2009 07:53:00 GMT

这本应是一个无须争论的问题——当然必须调用。

stdarg（或varargs，下略）中提供的功能就是一种契约：
“你按我的约定方式使用这些宏
——即必须调用va_end
——我就给你提供实现可变长参数列表所需要的功能。”

使用stdarg本来是很简单的事情
——按照一个简单的契约（另见相关链接）办事就可以了
——根本无须了解其具体实现。

有人乐意去研究该功能是如何实现的，也很好。

可是某些人
——或通过研究其的实现，或通过实践
——发现他所使用的平台下， va_end是可以忽略的。
之后，他就开始大放厥词： “va_end是不必要的！”

由此，造成一些不必要的误解与争论。

让我们看看对va_end的两种态度：

一、 va_end能省则省？

假设你使用的某个C/C++编译器，提供的va_end是可忽略的。
比如msvc中的va_end的实现如下：

#define va_end(ap) ap = (va_list)0 /* 将ap置空 */

通常直接使用va_start的函数（假设叫f）的实现体会很短。：
1. 用va_start初始化va_list
2. 调用一个使用va_list参数的函数（假设叫vf）
（vf 是一个固定参数列表的函数）。

因为f的实现体非常短，一眼望穿。
所以你能确保vf返回后， ap不会再被你使用。

因此，将ap置空除了浪费CPU周期，没有实际意义，是这样吗？

        一、1. 编译器参与优化

你能发现代码末尾ap不再被使用， va_end将其置空毫无意义。
那么，你的编译器能发现这个问题么？

请查证一下。
如果编译器也知道，并且没有为va_end生成任何代码，那么省略va_end就是不必要的了。

        一、2. 编译器不参与优化

你编译器真为va_end生成了无意义并且令人感到无法接受的机器码时，该怎么办？

                一、2.1 你只在该编译器下工作

那么，你省略va_end好了。
但请不要宣扬一些带有误导性质的言辞。
当你说“va_end是不需要”的时候，请附带说明：
1. 你的平台
2. 你不考虑跨平台

                一、2.2 需要要考虑移植到其他编译器

注意，其他编译器包括（但不限于）：
——不同架构上的编译器
——相同架构上的不同编译器产品
——相同架构上的相同编译器产品的不同版本。

需要分析在该编译器下，对va_end的处理是否依然可以被省略。
——显然，这是一项乏味的工作。

即使你在源代码中写入：

/* va_end is trivial, omit it */

也难保它不会被遗忘
—— 移植一个程序的时候有太多工作要做。
这么一个不起眼的地方，会被想起来么？

如果在被移植的编译器上：
1. 省略va_end将导致函数不能正常返回（见附录）
也许立马就能发现这个bug。
崩掉了嘛，当然要引起“重视”。

2. 省略va_end不会立马崩溃，而是导致内存泄露（见附录）
情况就很严重了。
程序依然运行“良好”。
但是调用一次函数，就泄漏一点点内存。

这恐怕就要花很多时间才能查出来了。
如果项目时间再紧一点，也许根本就来不及修复这个bug就发布了。
反正漏得也“不多”，你说是吧？

二、 va_end能留则留

我们何不换个方式？

1. 坚持使用va_end
——即便我们心里清楚它没做什么有用的事情也是如此。

代码移植本质就是：不对平台（CPU、OS、Compiler等等）产生依赖。
stdarg就是标准库提供的一种实现可变长参数列表的可移植方式。
我们没理由弃之不用。

如果我们在源代码中坚持使用va_end：
——至少在这点上，就不会对编译器产生依赖（而省略va_end，就是一种依赖）。
——移植的时候，自然无须为其操心。

2. va_end令编译器产生了令人无法接受的无用代码时
——通常，这是不会发生的。编译器厂商会考虑这个事情。

比如上面的va_end宏，会产生一次不必要的赋值操作，但通常会被编译器优化为空。
即使没有被优化为空，一次赋值操作，真的就是不可容忍的么？

如果确实不能容忍，作为一种特殊情形，可以这样：

#if defined(COMPILER1) || defined(COMPILER2) || ...
    /** special situation
        the machine code generated by these compliers is unacceptable, omit it
    */
#else
    /* general situation */
    va_end(ap);
#endif

附录 —— 看看大牛们是怎么说的。

从一个使用过va_start()的函数中退出之前，必须调用一次va_end()。
这是因为va_start可能以某种方式修改了堆栈，这种修改可能导致返回无法完成，va_end()能将有关的修改复原。
                ——《C++程序设计语言》第3版、特别版， p139
——即上面提到的 “立即崩溃”。

我们务必记住，在使用完va_list变量后一定要调用宏va_end。
在大多数C实现上，调用va_end与否并无区别。
但是，某些版本的va_start宏为了方便对va_list的遍历，就给参数列表动态分配内存。
这样一种C实现很可能利用va_end宏来释放此前动态分配的内存；
如果忘记调用宏va_end，最后得到的程序可能在某些机型上没有问题，而在另一些机型上则发生“内存泄露”。
                ——《C陷阱与缺陷》， p161
——即上面提到的“内存泄露”。

…… 最后，必须在函数返回之前调用va_end，以完成一些必要的清理工作。
                ——《C程序设计语言》第2版， p137

……在所有参数处理完毕后，且在退出函数f之前，必须调用宏va_end一次 ……
                ——《C程序设计语言》第2版， p232

编译器选项——语言

OwnWaterloo — Mon, 20 Apr 2009 07:02:00 GMT

一、统一的预处理、编译、链接程序

        一、1. 有些程序同时具有如下功能：

1. 预处理C/C++源代码
2. 编译C/C++源代码
3. 链接C/C++目标代码

例如：GCC的gcc、g++，MSVC的cl.exe。

        一、2. 实际的情况也许更加复杂：

gcc、g++、cl.exe很有可能只是一个启动器。
用户只需要使用它们，它们内部再根据特定条件，执行其他程序，比如：

1. gcc、g++编译C/C++代码时，最终会执行cc1/cc1plus程序。
该程序可能才是真正的C/C++编译器。

2. gcc、g++在链接C/C++目标代码时，最终会执行ld程序。
该程序可能才是真正的链接器。

3. cl.exe程序自己处理C/C++代码的预处理与编译工作。

4. cl.exe程序链接时，将执行link.exe。
该程序可能才是真正的链接器。

        一、3. 我们的关注点

——上述复杂的情况我们大多数情况下无须操心：

1. 我们只需要使用gcc、g++
即使以后GCC将cc1、cc1plus、ld改为别的名字也不会受影响。

2. 我们只需要使用cl
即使以后cl不再担任编译工作或者link.exe被改为别的名字，同样不受影响。

——我们需要关心这些统一的程序，是根据何种条件，决定它们的操作的？

本文只讨论编译：
1. 它们默认是通过何种条件，决定按C语法或按C++语法编译一个翻译单元的。
2. 如何显式指定按C语法或者按C++语法去编译一个翻译单元。

二、默认情况

如果不显式指定操作， gcc、g++、cl都是按文件后缀名来决定操作的。

二、1. 测试文件：

#ifndef __cplusplus
/* being treated as C translation unit */
#error !--- C ---!
#else
// being treated as C++ translation unit
#error !--- C++ ---!
#endif

我们建一个没有后缀的文件，叫nosuffix，写入如上内容。
而且，我们也不需要编译出目标代码。
只需要测试__cplusplus宏（见《预定义__cplusplus宏》）是否存在，并且用#error报告即可。

然后建立一些内容完全一样的文件：

#include "nosuffix"

这些文件共有10个：
c.c、 cpp.cpp、txt.txt、UC.C、UCPP.CPP、cc.cc、cxx.cxx、inl.inl、c++.c++、cp.cp。
（UC和UCPP是为了测试大写后缀名）

二、2. 测试方法

对GCC使用：
gcc(g++) filename >stdout.txt 2>stderr.txt

对MSVC使用：
cl filename >stdout.txt 2>stderr.txt

二、3. 测试结果

gcc、g++、cl对以下后缀名文件的默认操作如下表：

	nosuffix	.c	.cpp	.txt	.C	.CPP	.cc	.cxx	.inl	.c++	.cp
gcc	obj	C	C++	obj	C++	C++	C++	C++	obj	C++	C++
g++	obj	C++	C++	obj	C++	C++	C++	C++	obj	C++	C++
cl	obj	C	C++	obj	C	C++	C++	C++	obj	obj	obj

对该表的几点说明：
1. 表中的obj表示该条件下，统一程序将它们认作目标文件，并打算执行链接工作。
这显然是错误的，因为他们包含的是文本。

2. gcc、g++（编译代码）的区别
GCC认为带有.c、.cpp、.C、.CPP、.cc、.cxx、.c++、.cp（但不限于）后缀的文件是C/C++源文件。
gcc把带有.c后缀的文件，当作C源文件，把带有其他后缀名的文件当作C++源文件。
g++将带有上述所有后缀的文件，都当作C++源文件。

3. MSVC与GCC的区别
MSVC认为带有.c、.cpp、.C、.CPP、.cc、.cxx后缀的文件是C/C++源文件。
上述GCC相比，排除了.c++和.cp

同时，windows下的文件名是不区分大小写的，所以.c同.C，.cpp同.CPP是一样的。
与GCC相比， .C不再认为是C++源文件，而是与.c一样作为C源文件处理。

        二、4. 测试小结

由上表以及说明，如果我们打算编写跨平台的代码：

1. 不推荐使用的后缀名
.c++、.cp
——因为它们不被MSVC支持
.C
——因为MSVC并不区别对待.c与.C

2. 可以使用的后缀名
——对C源文件
可以使用.c。

——对C++源文件
可以使用.cpp、.cc、.cxx。

——.CPP不推荐
因为在xnix上 a.CPP与a.cpp是2个文件，而复制到Windows上就将发生重名。
如果只使用.cpp就可以避免该情况。

3. 关于.inl
有些文件内容确实是C/C++代码，但是却不直接作为翻译单元，而是被其他翻译单元包含。
理论上说，它们取任何名字都没关系。但是将它们取为.inl会得到一些好处：
    —— 暗示该文件包含C/C++代码
    —— 一些编辑器会对其按C/C++语法进行高亮。

三、显式指定

有时候需要覆盖默认情况，显式指定我们需要的操作。

        三、1. GCC “-x”

GCC通过-x选项显式指定编译源代码的语言：
-x c（或-xc）
    —— 将源代码作为C源文件。
-x c++、（或-xc++）
    —— 将源代码作为C++源文件。

对于“二”中的测试，只要将命令行改为：
gcc(g++) -x c (-xc) filename

所有文件都将被作为C源文件处理，并输出 error !--- C ---!

而使用如下命令行：
gcc(g++) -x c++ (-xc++) filename

所有文件都将被作为C++源文件处理，并输出 error !--- C++ ---!

        三、2. MSVC “/TC” “/TP”

MSVC通过/TC（/TP）选项，显式指定将输入作为C（C++）源代码。

对“二”中的测试，命令行：
cl /TC filename

对所有文件都将输出 error !--- C --- !

命令行：
cl /TP filename

对所有文件都将输出 error !--- C++ ---!

四、总结

1. 使用“二、4”中推荐的方式，给源代码文件命名。
2. 覆盖默认情况，使用-x(GCC)或者/TC、/TP（MSVC）
3. 顺带提一点， gcc、g++用作链接时，也有一些区别。
链接C++（或者C/C++混合）目标代码，推荐使用g++。
因为GCC高版本中， gcc链接时默认不会导入C++需要的运行时库。

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。

转载请注明：
文章作者 - OwnWaterloo
发表时间 - 2009年04月20日
原文链接 - http://www.cppblog.com/ownwaterloo/archive/2009/04/20/compiler_options_language.html

OwnWaterloo 2009-04-20 15:02 发表评论

预定义__cplusplus宏

OwnWaterloo — Mon, 20 Apr 2009 06:42:00 GMT

一、介绍预定义宏"__cplusplus"

        一.1 __cplusplus宏在C++标准中的描述如下：

16.8 Predefined macro names
__cplusplus The name __cplusplus is defined to the value 199711L when compiling a C++ translation unit.143)
143) It is intended that future versions of this standard will replace the value of this macro with a greater value.
Non-conforming compilers should use a value with at most five decimal digits.

                                        —— ISO C++03 p315
                                        —— ISO C++98 p309

如果一段代码是需要针对C++编写的，可以使用该宏进行条件编译。

        一.2 __cplusplus的值是为了表示C++的版本
        一.3 __cplusplus的类型是"long int"

——这是理论上的。
现在发布的C++标准只有C++98， C++03是C++98的修订，内容只有很少改变。
所以在ISO C++03中，也规定该宏的值是199711L（这是一个长整数字面值）。

——实际上，目前不应该依赖该宏的值，因为：
1. 目前标准中规定的值只有一个——199711L，没有根据该值进行条件编译的可能。

2. 目前C++编译器并不一定按标准实现这个宏（见测试）。

二、测试预定义宏__cplusplus

示例1：

#include <stdio.h>

int main() {

#define TO_LITERAL(text) TO_LITERAL_(text)
#define TO_LITERAL_(text) #text
#ifndef __cplusplus
/* this translation unit is being treated as a C one */
    printf("a C program\n");
#else
// this translation unit is being treated as a C++ one
    printf("a C++ program\n__cplusplus expands to \""
          TO_LITERAL(__cplusplus) "\"\n");
#endif
    (void)getchar();
    return 0;
}

代码很简单：
如果没有定义__cplusplus，那么当前源代码被当作C源代码处理。
如果定义了__cplusplus，那么当前源代码被当中C++源代码处理，并且输出__cplusplus宏被展开后的字符串。

示例2：

__cplusplus

这段代码更简单了，只是使用了__cplusplus宏。
然后查看预处理（见《查看源文件预处理结果》），看其被扩展后的结果。

三、测试结果

        ——msvc8
        ——msvc9
__cplusplus按照标准被扩展为——199711L。

        ——msvc6
        ——gcc (GCC) 3.4.2 (mingw-special)
        ——gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
__cplusplus只是简单的被扩展为——1。

这也说明了不应该依赖__cplusplus宏的值。

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。

转载请注明：
文章作者 - OwnWaterloo
发表时间 - 2009年04月20日
原文链接 - http://www.cppblog.com/ownwaterloo/archive/2009/04/20/predefined_macro___cplusplus.html

OwnWaterloo 2009-04-20 14:42 发表评论

预定义GNUC宏

OwnWaterloo — Thu, 16 Apr 2009 12:07:00 GMT

一、介绍预定义宏“__GNUC__”

        一.1 __GNUC__ 是gcc编译器编译代码时预定义的一个宏。

需要针对gcc编写代码时，可以使用该宏进行条件编译。

        一.2 __GNUC__ 的值表示gcc的版本。

需要针对gcc特定版本编写代码时，也可以使用该宏进行条件编译。

        一.3 __GNUC__ 的类型是“int”

该宏被扩展后，得到的是整数字面值。
可以通过仅预处理，查看宏扩展后的文本。见：《查看源文件预处理结果》
同时下面的示例也能体现出这一点。

二、测试预定义宏__GNUC__

示例：

#include <assert.h>
#include <stdio.h>
#include <typeinfo>

#ifndef __GNUC__
#error sample for gcc compiler
#else
/* use gcc special extension: #warning , __attribute__, etc.  */
#endif

int main() {
    printf("hello gcc %d\n",__GNUC__);
    assert( typeid(__GNUC__)==typeid(int) );
    printf("press Enter to exit\n");
    (void)getchar();
}

修改：

——2009/04/18

__GNUC__
__GNUC_MINOR__
__GNUC_PATCHLEVEL__
These macros are defined by all GNU compilers that use the C preprocessor:
C, C++, and Objective-C. Their values are the major version, minor version,
and patch level of the compiler, as integer constants. For example, GCC 3.2.1
will define __GNUC__ to 3, __GNUC_MINOR__ to 2, and __GNUC_PATCHLEVEL__ to
1. They are defined only when the entire compiler is in use; if you invoke the
preprocessor directly, they are not defined.

—— http://gcc.gnu.org/onlinedocs/gcc-3.1.1/cpp/Common-Predefined-Macros.html#Common%20Predefined%20Macros

相关链接：

——源代码
http://immature.googlecode.com/svn/trunk/iMmature/sample/predefined_macro/extension/__GNUC__/

——《查看源文件预处理结果》
http://www.cppblog.com/ownwaterloo/archive/2009/04/16/get_result_of_preprocessing.html

——《预定义_MSC_VER宏》
http://www.cppblog.com/ownwaterloo/archive/2009/04/15/predefined_macro__MSC_VER.html

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。

转载请注明：
文章作者 - OwnWaterloo
发表时间 - 2009年04月16日
原文链接 - http://www.cppblog.com/ownwaterloo/archive/2009/04/16/predefined_macro___GNUC__.html

OwnWaterloo 2009-04-16 20:07 发表评论

配置msvc命令行环境(续)——编写msvc编译脚本

OwnWaterloo — Wed, 15 Apr 2009 19:42:00 GMT

摘要: 为多个VC版本编写编译脚本阅读全文

OwnWaterloo 2009-04-16 03:42 发表评论

查看源文件预处理结果

OwnWaterloo — Wed, 15 Apr 2009 16:49:00 GMT

编译C/C++源代码时，源代码首先会被预处理器（preprocessor）进行预处理（preprocess）。
预处理器执行源代码中的预处理指令，如：
——文件包含
#include
——条件编译
#if、 #ifdef、 #ifndef、 #elif、 #else、 #endif
——宏
#define、 #undef、宏标识符、宏扩展
——其他
#error、#line、#pragma
……

预处理之后的结果（即将提交给编译器）与程序员看到的源代码也许会有很大的差异。
尤其在源代码中含有许多错综复杂的宏与条件编译时。
当我们被这些狂乱的宏与条件编译折磨的时候，如果能看到预处理的结果，也许会有很大的帮助。

下面将以一个示例说明msvc与gcc中得到预处理结果的方式。

零、示例

假设我们需要查看 _MSC_VER 与 __GUNC__ 两个宏最终被扩展出的文本：

int main() {
int result =
#if defined(__GNUC__)
__GNUC__
#elif defined(_MSC_VER)
_MSC_VER
#else
#error unknown compiler
#endif
;
return result;
}

该程序很简单， main函数返回一个result，然后立即退出。
而result的值，根据条件编译得到：
1. 如果是GCC编译器，那么result赋值为__GNUC__
2. 否则如果是VC编译器，那么result赋值为_MSC_VER
3. 否则是一个未知的编译器，错误

接下来，我们来看看_MSC_VER与__GNUC__这2个宏最终到底被扩展为什么文本。

一、 GCC

一.1、 -E 选项

-E选项将把预处理的结果，写入stdout。
也就是说，执行如下命令：
gcc -E preporcess_only.c

就能在控制台中得到预处理后的结果，大致如下：

# 1 "../preprocess_only.c"
# 1 ""
# 1 ""
# 1 "../preprocess_only.c"
int main() {
int result =

3

;
return result;
}

可以看到， __GUNC__ 宏最终被扩展为整数字面量3（GCC 3）。

如果源代码很长，输出到命令行窗口中查看也许不方便。
如何将其输出到一个文件中呢？

                一.1.1、重定向

因为-E是输出到stdout，显然可以将其重定向到另一个文件，如执行如下命令：
gcc -E preprocess_only.c >stdout.txt

那么stdout.txt中，就能得到刚才命令行窗口中的内容。

                一.1.2、 -o （小写）选项

-o选项用于指定出文件名。
对于-c， -o指定的是目标文件名。
对于-S ，-o指定的是汇编文件名。
对于-E， -o自然也可以指定预处理文件名，如执行如下命令：
gcc -E preprocess_only.c -o output.txt

那么output.txt中会得到“一.1.1”中的stdout.txt和“一.1”中控制台窗口一样的结果。

        一.2、-save-temps 选项

-save-temps选项将保留中间文件：如预处理后的结果文件、汇编代码文件与目标文件。
其中的预处理结果文件（通常有.i后缀）是我们所需要的。

举例：
1、 gcc -save-temps -E preprocess_only.c
0个中间文件。
输出预处理结果，同“一.1”一样，输出到控制台窗口中。
对比如下命令：

1.1、 gcc -save-temps -E preprocess_only.c -o temp_output.txt
1.2、 gcc -save-temps -E preprocess_only.c >temp_output.txt
可以看出， -E选项不产生中间文件。预处理结果就是最终结果。
同时可以使用 -o选项或者重定向，把结果保存到一个文件中。

2、 gcc -save-temps -S preprocess_only.c
1个中间文件： preprocess_only.i（预处理结果）
1个输出文件：preprocess_only.s（汇编代码）
对比如下命令：

2.1、 gcc -save-temps -S preprocess_only.c -o unknown
得到preprocess_only.i文件，内容是预处理结果，是中间文件。
得到unknown文件，内容是汇编代码，是最终结果文件。

3、 gcc -save-temps -c preprocess_only.c
2个中间文件： preprocess_only.i与preprocess_only.s。
1个输出文件： preprocess_only.o（目标代码）
对比如下命令：

3.1、 gcc -save-temps -c preprocess_only.c -o unknown
得到preprocess_only.i 与 preprocess_only.s文件，内容分别是预处理结果与汇编代码，是中间结果。
unknown文件，内容是目标代码，是最终结果文件。

4、 gcc -save-temps preprocess_only.c
3个中间文件： preprocess_only.i、preprocess_only.s、preprocess_only.o。
1个输出文件： a.out（a.exe with mingw）。
对比如下命令：

4.1、 gcc -save-temps preprocess_only.c -o what
得到上述3个文件，是中间文件。
what文件（what.exe with mingw），内容是可执行代码，是最终结果文件。

二、 MSVC

VC6、8、9中与查看预处理相关的选项可以通过如下命令查看：
cl /help

在输出中，找 -PREPROCESSOR- 这个类别。
其中与预处理结果相关的有如下一些选项：

二.1、/E 选项

/E preprocess to stdout
/E 将预处理定向到 stdout

显然，这和“一.1”是等价的，如：
cl /E preprocess_only.c

在命令行窗口中将得到类似结果：

#line 1 "preprocess_only.c"
int main() {
int result =

#line 6 "preprocess_only.c"
1200

#line 10 "preprocess_only.c"
;
return result;
}

可以看到， _MSC_VER宏最终被扩展为整数字面值1200（VC6）。

对于较长的源文件，我们同样希望将结果输出到一个文件中。

                二.1.1、重定向

执行：
cl /E preprocess_only.c >stdout.txt

stdout.txt将保存上面的结果。

注意：在msvc中，没有“一.1.2”的对应物。
执行：
cl /help

在输出中找到-OUTPUT FILES-类别，可以看到没有命名预处理结果的方式。有两个相似的选项：
/Fe 命名可执行文件。
/Fp 命名预编译头文件。
但不是我们需要的选项。

也许VC认为通过 “/E + 重定向”就可以达到命名输出文件的目的。
所以就没有设计达到此目的的另一种方法。

        二.2、/P 选项

/P preprocess to file
/P 预处理到文件

执行：
cl /P preprocess_only.c

将得到 preprocess_only.i

/P会将对 xxx.suffix 的预处理结果输出到 xxx.i 文件中。
没有指定文件名的方式。如果需要指定输出文件名，可以使用 “/E + 重定向”

        二.3 /EP 选项

/E与/P选项都将保留一部分（源文件）行信息，如“二.1”所示。
如果这是不需要的，可以使用 /EP选项。

/EP preprocess to stdout, no #line
/EP 预处理到标准输出，没有 #line

如：
cl /EP preprocess_only.c

将得到如下输出：

int main() {
int result =

1200

;
return result;
}

同样，如果需要输出到指定文件，可以使用重定向。

二.4 其他一些有趣的选项

1. /C （大写）
don't strip comments（不抽出注释）
如果保留注释对理解预处理结果有帮助，可以使用这个选项。

2. /U /u
/u remove all predefined macros
/u 移除所有预定义的宏

/U remove predefined macro
/U 移除预定义的宏

比如可以通过：
cl /u preprocess_only.c
cl /U_MSC_VER preprocess_only.c

来得到一个 unknown complier错误囧……

3. /D
/D{=|#} define macro
/D{=|#} 定义宏

可以通过：
cl /D__GUNC__=3 preprocess_only.c

来假装gcc编译器囧……

相关链接：

——示例文件下载
http://immature.googlecode.com/svn/trunk/iMmature/sample/compiler_options/preprocess_only/
http://www.cppblog.com/Files/ownwaterloo/preprocess_only.zip

——《配置msvc命令行环境》
http://www.cppblog.com/ownwaterloo/archive/2009/04/15/environment_for_using_cl_from_command_line.html

——《配置msvc命令行环境(续)——编写msvc编译脚本》
http://www.cppblog.com/ownwaterloo/archive/2009/04/16/write_compile_script_for_msvc.html

——《预定义_MSC_VER宏》
http://www.cppblog.com/ownwaterloo/archive/2009/04/15/predefined_macro__MSC_VER.html

——《预定义__GNUC__宏》
http://www.cppblog.com/ownwaterloo/archive/2009/04/16/predefined_macro___GNUC__.html

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。

转载请注明：
文章作者 - OwnWaterloo
发表时间 - 2009年04月16日
原文链接 - http://www.cppblog.com/ownwaterloo/archive/2009/04/16/preprocess_only.html

OwnWaterloo 2009-04-16 00:49 发表评论

配置msvc命令行环境

OwnWaterloo — Wed, 15 Apr 2009 13:29:00 GMT

有些时候使用命令行而不是IDE去编译源代码会比较方便。
而在命令行下使用msvc的编译器——cl，需要为其配置环境。

一、环境变量测试

测试cl的环境是否配置妥当，可以执行如下测试：
win键+R 启动运行 -> 输入cmd（winnt系列）或者command（win95系列） -> 回车，打开命令行窗口。
键入"cl"并回车，如果有类似如下的输出：

--------------------------------------------------------------------------------
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]
--------------------------------------------------------------------------------
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]
--------------------------------------------------------------------------------
用于 80x86 的 Microsoft (R) 32 位 C/C++ 优化编译器 15.00.30729.01 版
版权所有(C) Microsoft Corporation。保留所有权利。

用法: cl [ 选项... ] 文件名... [ /link 链接选项... ]

--------------------------------------------------------------------------------

一般来说，就可以在命令行下使用cl了。

cl文件版本与VS版本、VC产品版本、_MSC_VER宏的对应关系如下表：

VS版本	VC产品版本号	cl文件版本号	_MSC_VER宏的值
98	6.x	12.x	1200
2005	8.x	14.x	1400
2008	9.x	15.x	1500

二、测试失败

如果出现：
1. “cl不是内部或外部命令，也不是可运行的程序或批处理文件。”
说明cl不在Path环境变量中。

2. 找不到xxx.dll。
cl在Path环境变量中， Path中缺少必要的dll的路径。

3. 上述测试通过，但是在编译时出现找不到头文件或者库。
说明Path环境变量中有cl和必要dll的路径，但是仍缺少其他一些环境变量。

这些情况，都需要进一步配置环境变量。

三、配置环境变量

        三.1 、让安装包帮助注册环境变量

VC6在安装的时候，会弹出一个对话框，让你选择是否注册VC6的环境变量。如下：

For your convenince, the environment variables required to run build tools from a command prompt are saved in the VCVARS32.BAT in your BIN directory

（复选框） Register Environment Variables

Turn on this option to register environment variables for running Visual C++ tools from the command line.

默认复选框是没有选中的。
如果选中，安装完毕后就会添加必要的环境变量。

所以，一个办法是重新安装VC6（反正很小，相对于VC8、9安装十分快速）。

        三.2 、手工添加环境变量

以VC6举例，我们可以在：“我的电脑” -> “属性” -> “高级” -> “环境变量”中添加如下变量：

%Path%="prefix\Microsoft Visual Studio\VC98\Bin";%Path%
cl.exe所在路径。

%include%="prefix\Microsoft Visual Studio\VC98\Include";%include%
%lib%="prefix\Microsoft Visual Studio\VC98\Lib";%lib%
C/C++以及Platform SDK

%include%="prefix\Microsoft Visual Studio\VC98\MFC\Include";%include%
%lib%="prefix\Microsoft Visual Studio\VC98\MFC\Lib";%include%
MFC

%include%="prefix\Microsoft Visual Studio\VC98\ATL\Include";%include%
ATL

（其中的prefix是安装目录的前缀）之后就可以在命令行中使用cl了。

同时， VC6、8、9都提供了一个批处理vcvars32.bat。
我们可以查看相应的vcvars32.bat最终做了什么工作，而手工加入需要的变量。
下内容摘自我机器上的vsvars32.bat（VC8、9的vcvars32.bat最终调用它们）：

vc8

vc9

可以根据它们，给VC8、9设置环境变量。

三.3 、使用vcvars32.bat

上面提到vcvars32.bat，它们的位置如下：

VC6 prefix\Microsoft Visual Studio\VC98\Bin\VCVARS32.BAT
VC8 prefix\Microsoft Visual Studio 8\VC\bin\vcvars32.bat
VC9 prefix\Microsoft Visual Studio 9.0\VC\bin\vcvars32.bat

需要注意的是：这些批处理文件只会在当前进程中设置（局部的）环境变量，也就是说：

1. 用cmd（或者command）打开的命令行窗口中，运行某个vcvar32.bat一次。
那么当前命令行窗口中就可以正常使用cl，直到关闭。

2. 写批处理文件需要使用call prefix\vcvars32.bat，而不是直接启动vcvars32.bat。
前者为当前进程（cpl.bat创建的进程）添加局部于进程环境变量。
后者启动一个进程，为其加入环境变量，然后该进程立即退出——没有任何作用。

三.4、使用VSXXCOMNTOOLS变量（VC8、9）

对于VC8、9有另一种方式——不注册全局的（系统或当前用户）环境变量，仅为当前进程设置（局部的）环境变量。
因为VC8、9都可以很方便的为单个进程设置环境变量。

观察vc8和vc9的vcvars32.bat的内容（位置见上），发现它们都只有一行：
"%VS80COMNTOOLS%vsvars32.bat"
"%VS90COMNTOOLS%vsvars32.bat"

VS80COMNTOOLS、VS90COMNTOOLS（注意不是VC而是VS）分别是VS2005和VS2008安装后会设置的环境变量。
所以我们也可以在自己的批处理中，很方便的为当前进程设置需要的环境变量。如下：

call "%VS80COMNTOOLS%vsvars32.bat"
以下cl命令将执行VC8的cl。

call "%VS90COMNTOOLS%vsvars32.bat"
以下cl命令将执行VC9的cl。

四、总结

如果仅需要使用某个版本的VC，并且只为自己方便而使用命令行，可以使用上面任何一种方式。
简单归纳如下：

1、使用全局环境变量——在系统或当前用户变量中加入需要的值。
        1.1 重新安装
        1.2 手工加入

2、不使用全局环境变量
——在执行cl前，先使用对应的vcvars32.bat（命令行窗口中执行或者脚本中call prefix\vcvars32.bat）。

        2.1 将vcvars32.bat加入Path变量
        2.2 使用"%VSXXCOMNTOOLS%vsvars.bat" (VC8、9）或者 absolutePath\vcvars32.bat

如果需要使用多个版本的VC、或者需要将编译脚本发布给客户使用，就不能这么随意了。
具体见：《配置msvc命令行环境(续)——编写msvc编译脚本》

——《IDE 不是程序员的唯一选择（一）》
http://blog.codingnow.com/2008/09/replacement_of_ide_1.html

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。

转载请注明：
文章作者 - OwnWaterloo
发表时间 - 2009年04月15日
原文链接 - http://www.cppblog.com/ownwaterloo/archive/2009/04/15/environment_for_using_cl_from_command_line.html

OwnWaterloo 2009-04-15 21:29 发表评论