说不上来，但有点感觉楼主是在调戏连接器，而连接器却并不知道自已在反调戏。
这个程序在g++上的效果确实如楼主所言，但却整死了VC2003所用的cl。

嗯，刚才我就被他整死了。。。

符号表！
对连接器来说，所有符号表的入口都是指针，没有通过符号表直接查变量值这一说。
对于函数名，这个地址就是函数的入口地址，对于变量来说，这个地址就是变量存储的位置。

所以，当连接器处理这条语句时：
cout<<hex<<int(main)<<endl;
时，实际上是这么处理的：

（1）在符号表中查找“main”这个名字，查找它所对应的地址。
（2）到那个地址上去读，把里面的内容解释成一个char，找印出来。

打错了，“找印”->“打印”。

extern char main;//这个想干嘛

去掉看看

我的输出是40146a

还是intel编译器牛：
error: declaration is incompatible with previous "main" (declared at line 26)
      extern char main;

呵呵。偶也觉得该报错才好。

如果不在同一个编译单元中，不报错还稍微有情可援。

问题是这句
extern char main;
这句肯定会造成符号重定义.当然,gcc这个变态支持这么写....
在这种情况下.
在main函数里又多了一个名称为main的变量,它的地址刚好是main的入口....
值也理所当然的是main函数的第一个字节.

说白了,这种东西就是自己强奸自己...

其实这个程序和下面的代码是一样的,不过下面的是合法的...
#include <iostream>
using namespace std;
int main()
{
  char &a = *(char*)(void*)main;
  cout<<hex<<int(a)<<endl;
  return 0;
}

符号表！
对连接器来说，所有符号表的入口都是指针，没有通过符号表直接查变量值这一说。
对于函数名，这个地址就是函数的入口地址，对于变量来说，这个地址就是变量存储的位置。
 
所以，当连接器处理这条语句时：
cout<<hex<<int(main)<<endl;
时，实际上是这么处理的：

（1）在符号表中查找“main”这个名字，查找它所对应的地址。
（2）到那个地址上去读，把里面的内容解释成一个char，找印出来

谢谢晨星老大：
我终于明白了。。。呵呵。对连接器来说，所有符号表的入口都是指针，没有通过符号表直接查变量值这一说。


------------------- 
 回复人：redleaves(程序员) ( 五级(中级)) 信誉：110  2006-12-31 17:03:23  得分:0
? 
问题是这句
extern char main;
这句肯定会造成符号重定义.当然,gcc这个变态支持这么写....
在这种情况下.
在main函数里又多了一个名称为main的变量,它的地址刚好是main的入口....
值也理所当然的是main函数的第一个字节.

说白了,这种东西就是自己强奸自己...

extern char main，并不会造成符号的重定义，他的地址也不是说“刚好”是main的入口。而是如晨星老大所说的。你也可以试着把extern char main放到另外的一个文件中如：
//1.cpp
#include <iostream>
using namespace std;

extern char Getmain();
int main()
{
    //这里多写一些内容，就不存在刚好等于main地址这个说法
    int a=20;
    int b=30;
    .....
    cout<<hex<<(int)Getmain()<<endl;

    system("pause");
    return 0;
}
//2.cpp
extern char main;

int foo()
{
  return main;
}

另外：TO 晨星老大.甘草GG

想来想去，你们俩的可用分是不是可以考虑转让给我啊。。。反正放着闲着也是闲着啊。你看我多惨啊。集的半死才够100分问个问题，现在又没了啊。。。感激不尽啊。。。。

能不能顺便给我一点儿啊？
^_^

猩猩级别人物就不要跟我抢了吧。。。..>>>!>>!>

R9R9R9(猪头饼@超越平庸，选择完美) ( ) 信誉：100    Blog  2006-12-31 20:26:54  得分: 0  

另外：TO 晨星老大.甘草GG

想来想去，你们俩的可用分是不是可以考虑转让给我啊。。。反正放着闲着也是闲着啊。你看我多惨啊。集的半死才够100分问个问题，现在又没了啊。。。感激不尽啊。。。。
==========================================================================
你不早说，刚刚散光。。。- -b
  
 

TO R9R9R9
int main();
extern char main;
大哥,这种写法不重定义,哪种会重定义?如果写在两个文件里,链接器当然不知道这两个是不同的东西啦~
你应该好好研究一下编译器,链接器的工作原理.我很早以前写的关于COFF格式的文章,看下吧.试着自己写写编译器,链接器.就明白我在说什么了.
http://dev.csdn.net/article/21/21076.shtm

另外,楼主可以看一下C++03标准的章节3.5.
你写的那种东西在语法上属于第9种,两个同样的外部链接名称,所指向的是同一个东西.
第10条又说,对于指向同一个东西的名称,它们的类型应该一致.但允许不做出诊断(主要是多个编译单元时处理起来不方便..)
(嘿嘿,可能俺翻译得"朴实"了点,不过意思是这样的.俺不喜欢写过多晦涩的"专业"名词)

说句题外的话,gcc也真是够偷懒的,虽然C++标准说对于这种类型不一至的情况,可以不用诊断.但人家那是针对多个编译单元难于处理说的.而它在同一个编译单元里,硬是不管...
死活不明白,为什么总是有人要吹捧它,说它支持标准好...其实如果仔细研究一下,gcc比哪个C++编译器支持得非标准内容都多,而且多半是对C++语法行为的改进,并且没什么文档说明.不同版本的语法,说改就改.而网上那些奇怪的代码,多半是要用gcc的特定版本才能编译的...

真的要研究C++,用Visual C++(7,8),Intel C++,Metrowerks C/C++都比用gcc要好得多...

TO:  redleaves(程序员)

谢谢您的指导，昨天想当然认为extern char main，只是声明了一个变量，所以就认为不会造成符号的重定义，我知道我错了。其实会生成一个extern 符号，也就是未定义的全局变量，是一个弱符号。所以链接的时候选择了main函数的这个强符号。

另外感谢你的回复，我正在看的就是链接器的符号解析过程,但水平有限，所以才发贴求问的，您不要动怒啊，我有什么地方说错的。请大家指正。感激不尽啊。

呵呵,可能我语气强烈了点....不过完全没有其它的意思.

问题是这句
extern char main;
这句肯定会造成符号重定义.当然,gcc这个变态支持这么写....

谢谢您的指导，昨天想当然认为extern char main，只是声明了一个变量，所以就认为不会造成符号的重定义，我知道我错了。其实会生成一个extern 符号，也就是未定义的全局变量，是一个弱符号。所以链接的时候选择了main函数的这个强符号。
--------------------------------------------------
这里本来就不是重定义，而只是错以为main函数的导出地址是char变量main的地址而已

extern char main当然是声明。
你说的弱符号是这种情形：char main;也就是没有初始化的全局量。
而extern char main是声明，只是变量main的定义在别处

摘自CS:APP (不知道你是否看的也是这本书，:> )
UNDEF is for undefined symbols, that is, symbols that are referenced in this object module but defined elsewhere. COMMON is for uninitialized data objects that are not yet allocated.
也就是说在linux ELF下, char main会放在COMMON段，而extern char main会放在UNDEF段


虽然上面是针对C语言讲的，但声明定义以及链接的基本概念是一样的。

据我所知，由于C语言下全局导出符号简单的以下划线标识，如_main，所以不管你类型是否一致，拿来就是。也就是说，a文件中定义的double i; 到b文件中就可以引用为extern int i;
并把a文件中为double变量导出的地址，拿到b文件中当int 变量i的地址来使

至于C++中，由于有了name-mangling，就可以知道每一个变量(准确点说是对象)的类型，所以出现上述这种情形时，可以分辨出来。

不过正如redleaves(程序员) 所说，
“对于指向同一个东西的名称,它们的类型应该一致.但允许不做出诊断”

TO blue_zyb
呵呵,你当然可以认为定义同样的名称,类型却不同不算做重定义(尤其是这种外部类型).这只是每个人的说法不同而已.在这点上没什么可争论的.重要的是这样做肯定会有歧义.

在ELF格式中,不同类型的东西会放在不同的段里,这也没什么可说的,这种东西在编译器实现的时候有很大的灵活性.在a.out/coff中,更加可以随意放到你想放的任何地方.反正最后只做名称查找.所以虽然coff本身含有类型信息,但是这种东西远远跟不上变化的节奏,也是形同虚设.不光是C++,C也是一样.因为编译和连接在最初的编译器体系中是脱节的,为了兼容,一直延续到现在.你可以看C的标准,对这种东西也有类似的定义.

呵呵,至少,我认为,不同类型的东西,名字却一样,而且无法分辨(因为是外部符号,可见域是相同的).那就是符号重定义.至少通常遇到这种错误的时候,我们的原意是要定义两个不同的东西.

另外,我所说的"弱符号"就是指那种只有名称,没有实体的符号.和你所说的全局变量没什么关系...呵呵

呵呵,至少,我认为,不同类型的东西,名字却一样,而且无法分辨(因为是外部符号,可见域是相同的).那就是符号重定义.至少通常遇到这种错误的时候,我们的原意是要定义两个不同的东西.
-----------------------------------
可能我更抠住了C和C++中关于定义和声明的区别。像extern char main;这样的东西，只是声明，该编译单元并不会为它分配存储空间，而是引用。它的定义在别处，也即在其它地方分配存储。所以，如果紧扣声明和定义的区别，这就不会构成重"定义",而只是引用出错。


另外,我所说的"弱符号"就是指那种只有名称,没有实体的符号.和你所说的全局变量没什么关系...呵呵
----------------------------------------------
关于弱符号的问题，我是从CS：APP中看来的:
At compile time, the compiler exports each global symbol to the assembler as either strong or weak, and the assembler encodes this information implicitly in the symbol table of the relocatable object file. Functions and initialized global variables get strong symbols. Uninitialized global variables get weak symbols.

Given this notion of strong and weak symbols, Unix linkers use the following rules for dealing with multiply-defined symbols:
 Rule 1: Multiple strong symbols are not allowed.
 Rule 2: Given a strong symbol and multiple weak symbols, choose the strong   
           symbol.
  Rule 3: Given multiple weak symbols, choose any of the weak symbols.

而且，好像你也一直没有提到"弱符号"这个名词，是lz提到了，我的话是说给lz听的。。。

不知道你对外部符号怎么看,事实上,所有的外部符号都是声明(有时可能也是定义).
而你也要看清楚我所说的东西"符号重定义",和语言本身没有关系.只是说明定义了两个同名不同意的"符号".这里的符号只是目标文件里的一个名称.和它是不是变量的声明/定义没有关系.

如果你所说的弱符号是上面给出的定义,那可能是你还没有完全理解.我们(的确不是我说的.前面是少打个字,我是帮楼主回答的.呵呵^_^)所说的东西和你给的东西是一样的.弱符号就是那种在目标文件中只有名称,没有实体的东西.通常只有外部变量,非内部函数是"确切"的弱符号.你所说的全局变量是个特例,未初始化的全局变量不是没有实体,只不过实体是可以忽略的,在COFF中通常是放在.BSS中.在COFF文件中不占实际空间的.如果编译器实现给它分配了空间,那也是无可厚非的.

不知道你对外部符号怎么看,事实上,所有的外部符号都是声明(有时可能也是定义).
而你也要看清楚我所说的东西"符号重定义",和语言本身没有关系.只是说明定义了两个同名不同意的"符号".这里的符号只是目标文件里的一个名称.和它是不是变量的声明/定义没有关系.

如果你所说的弱符号是上面给出的定义,那可能是你还没有完全理解.我们(的确不是我说的.前面是少打个字,我是帮楼主回答的.呵呵^_^)所说的东西和你给的东西是一样的.弱符号就是那种在目标文件中只有名称,没有实体的东西.通常只有外部变量,非内部函数是"确切"的弱符号.你所说的全局变量是个特例,未初始化的全局变量不是没有实体,只不过实体是可以忽略的,在COFF中通常是放在.BSS中.在COFF文件中不占实际空间的.如果编译器实现给它分配了空间,那也是无可厚非的.

弱符号就是那种在目标文件中只有名称,没有实体的东西.通常只有外部变量,非内部函数是"确切"的弱符号.
------------------------------------------------------
首先，请问你的这一句定义是否有文献可寻？另外请按照此定义举几个弱符号的例子

另外，非内部函数是弱符号是什么意思，也请举个"非内部函数"的例子
如果按照上面的摘文：
 Functions and initialized global variables get strong symbols. Uninitialized global variables get weak symbols.
函数应该都是强符号。


最后，从lz的这段话
---------------------------------------------------
谢谢您的指导，昨天想当然认为extern char main，只是声明了一个变量，所以就认为不会造成符号的重定义，我知道我错了。
----------------------------------------------------
显然，他指的"符号重定义"是和变量的声明和定义概念相关的。而我们在C/C++环境下讲到定义就自然会以为指的是存储对象的定义，而不会理解为你说的:
"而你也要看清楚我所说的东西"符号重定义",和语言本身没有关系.只是说明定义了两个同名不同意的"符号".这里的符号只是目标文件里的一个名称.和它是不是变量的声明/定义没有关系"

否则，在C/C++中，只要出现符号重"定义"，链接器就要报错了。
当然，如果你要从编译器，链接器的角度诠释符号重定义(或者说是符号声明),我也不置可否。

redleaves(程序员) 和 blue_zyb两位朋友。我给你们发短消息了，请查收，呵呵

to:lz
其实会生成一个extern 符号，也就是未定义的全局变量，是一个弱符号。所以链接的时候选择了main函数的这个强符号。
----------------------------------------------
从你说的"链接的时候选择了main函数的这个强符号。"这种说法，可以看出涉及就是链接器对于"multiply-defined symbols"的选择问题，那么也应该契合CS：APP中所述的强弱符号的概念。如果你愿意的话，可以出来为你的术语“弱符号”正一下名 :)

假设你的弱符号与我所指的是同一概念，那么extern char main确实只是声明，构不成定义，所以不存在"multiply-defined symbols"的选择问题。这种"强弱符号选择"问题的例子是:
a文件中定义了main函数体，是一个强符号
b文件中定义了char main; (未初始化)，是一个弱符号，那么链接的时候会根据
Rule 2: Given a strong symbol and multiple weak symbols, choose the strong symbol.
选择main函数这个强符号,而不会报错.

但如果在b文件中定义的是char main = 'a'; 也是强符号，那么由于
Rule 1：Multiple strong symbols are not allowed
链接器就会报错


回到你的问题，先把我上面摘过的一段话再抄一遍：
UNDEF is for undefined symbols, that is, symbols that are referenced in this object module but defined elsewhere. COMMON is for uninitialized data objects that are not yet allocated.

extern char main;声明了一个在其它文件中定义的main变量，在本文件的符号表中，它被放在UNDEF（比如在Unix系统下，其他系统类似，只不过名称细节有所不同).这和与弱符号概念相关的uninitialized data objects是不相同的，后者放在COMMON段。

等到链接器按照上面讲到过的的3个RULE解析完多符号的定义问题，并且没有出错后，必然有一个最终的main定义，然后链接器会对进行extern char main进行重定位(relocation),让它指向最后挑出的这个唯一的main定义。用CS：APP的话来说就是，
associated each symbol reference in the code with exactly one symbol definition

所以，extern char main; 与main()函数的关键关系是 relocation
而    char main;

不好意思，最后一句没写完就提交了...

所以，extern char main; 与main()函数的关键关系是 relocation，让char main指向main函数
而    char main;        与main()函数的关键关系是 "multiply-defined symbols"的选择

关于强符号和弱符号的定义的具体定义我还真说不出来是在哪儿看的.只是我记忆中的概念而已.

而且我看你所说的内容,似乎认为声明不会引入符号....
你反复说"extern char main确实只是声明，构不成定义",那我很想知道,如果
// a.cpp
extern char a;
a = "c";
这里的extern char a;不引入符号,下面所用的a不会产生"符号"未定义么?而目标文件里的外部符号a是什么?如果引入了符号,那这个符号是不是弱符号呢?而定义冲突时,不叫符号重定义,叫什么呢?
至少我认为它引入了符号,是个弱符号,并且对于符号实体的选择是在链接时完成的.也就是你所说的"multiply-defined symbols"的选择问题.所以理所当然,发生冲突时就是符号重定义.
另外,关于符号重定义的问题,我也想澄清一下.C++里所有的东西只能"定义"一次.也就是只能有一个实体(强符号)(函数重载之类的是引入了多个符号的).而声明所引入的弱符号可以有多个.并且要求指向同一个对象的名称(符号)是"完全一样"的--类型也要是一样的.如果类型不一样,也理所当然的是"符号重定义".当然,标准里有点放松,类型不同可以不要求做出诊断,这也是因为跨编译单元而做的让步而已(也可能是为了兼容C的二进制接口).

强弱符号示例如下:
int a(); // 引入弱符号
int a(); // 引入弱符号
int a() {} // 引入强符号
int c; // 引入强符号
int c; // 引入强符号,符号重定义,跨编译单元时是链接时报错.
extern int b; // 引入弱符号
extern int b; // 引入弱符号
extern char b; // 引入弱符号,符号重定义,跨编译单元可以不检测.
int b; // 引入强符号,上面的弱符号指向这个定义

而且我看你所说的内容,似乎认为声明不会引入符号....
你反复说"extern char main确实只是声明，构不成定义",那我很想知道,如果
// a.cpp
extern char a;
a = "c";
这里的extern char a;不引入符号,下面所用的a不会产生"符号"未定义么?
--------------------------------------------------------------------
我并没有说extern char a;没有引入符号,它引入了一个"引用"符号，就像我前面讲过几次的:
UNDEF is for undefined symbols, that is, symbols that are referenced in this object module but defined elsewhere.

但是，在C/C++语言中,该声明语句并不会引起在本编译单元中为之分配存储，而只是发表声明说：“其他文件中定义了一个叫a的对象，我想引用它，请链接器在链接的时候，把我所声明的a与实际的a定义关联起来。"

也就是说，在链接阶段，会把a.cpp中的a的地址重定位(reloation)为其他文件中为a分配的地址。比如b文件中有int a = 10; b编译单元为a分配了地址0x1000，在链接的时候a编译单元中的char a就与0x1000号地址相关联。


至少我认为它引入了符号,是个弱符号,并且对于符号实体的选择是在链接时完成的.也就是你所说的"multiply-defined symbols"的选择问题.
--------------------------------------------
如果你看了我的文字，我的阐述很明确，extern char main;不参与"multiply-defined symbols"的选择问题;而是在选择这一步骤以后，对extern char main中的main声明进行relocation。 char main; 才参与符号选择问题。


最后，我想说明的一点是: C 和 C++在处理强弱符号这一点上确实是有区别。像int c;这样的语句在C语言中是一个弱符号；所以如果另一个文件中有char c = 'a';链接时将不会报错而选择char c;在C++中则会报错。但我不确定C++中对强弱符号的具体划分，因为没有看过相关的资料...

如果你把符号的选择仅限定在编译过程中,而不包括链接.那的确如你所说.
但对符号的选择并不仅仅是局限在编译过程,在链接过程中对符号也要进行选择,而这种选择就表现为重定位.如果这个过程有符号冲突,也会表现为符号重定义.
实际上,在编译过程中,对于符号的选择也是类似的情况.只是定位的过程不是那么直接而已.

当然,如果你认定你所说的"multiply-defined symbols"选择问题不包括链接时的符号选择,那我也无话可说.

另外,至于你所说的C里的那些现象,是和C++有所不同.
在C里int a;只是尝试定义a,如果成功,则产生一个强符号,如果失败,则产生一个弱符号指向前面的定义.而且在多个文件中都定义了int a,那就会有多个强符号,最后会链接失败(这点上和C++相同).不过这是C99标准才改进的.旧的C则不是这样.只是,似乎只有gcc实现了这个特性.

至此,我想我们已经把这个问题说得很明白.至于在说法上是怎么样,我想那并不重要,只要大家心里知道这是怎么回事就可以了.和你讨论这个问题让我把这些又温习了一便,很不错~.呵呵^_^

另外,如果你所说的"multiply-defined symbols"只是针对C里
int a;
int a;
这类情况.我想,它对C++是不适用的.因为C++里有"一次定义原则".在C++里,不可能有多个"定义"的选择问题.有的只是对符号名和它指向的符号实体的选择.

当然,如果你认定你所说的"multiply-defined symbols"选择问题不包括链接时的符号选择,那我也无话可说.
------------------------------
晕，我说的就是链接时的选择问题
我引用过的话：
Given this notion of strong and weak symbols, Unix linkers use the following rules for dealing with multiply-defined symbols:
是linkers，not compilers

但对符号的选择并不仅仅是局限在编译过程,在链接过程中对符号也要进行选择,而这种选择就表现为重定位.如果这个过程有符号冲突,也会表现为符号重定义.
-----------------------------------------------------
在C语言的前提下，
extern char main;是不会参加选择的，而只参与重定位。所以不会与main的实际定义发生“符号重定义”的冲突。
char main;是参与选择的;如果没被选上，它也会被重定位到main的真正定义,这倒是不假。

例如，假设a.c有：

void fun();
float x = 1.0;            // initialized，strong symbol

int main()
{
     fun();
     return 0;
}

b.c有：

int x;             // uninitialized，weak symbol
void fun()
{

printf("%x", x);
}

那么，由于b.c中的int x是弱符号，所以选择了a.c中的强符号float x。那么，最终，b.c中的x
会被重定位到float x的地址,但在本编译单元内，仍然作为int来解释。

所以，printf("%d", x);输出的并不是0，而是float 1.0 的int 解释。

另外,如果你所说的"multiply-defined symbols"只是针对C里
int a;
int a;
这类情况.我想,它对C++是不适用的.因为C++里有"一次定义原则".在C++里,不可能有多个"定义"的选择问题.有的只是对符号名和它指向的符号实体的选择.
------------------------------------------------------
最后说的这段话倒是同意，可能我前面没有好好强调我说的那一套是在C语言中，失误，呵呵~

to: redleaves(程序员) 和 blue_zyb

首先谢谢你们两个的讨论，看了好久，又明白了很多东西，原先我不知道CSDN结贴后还能继续的回贴，所以一直没有留意这个贴子，今天不小心GOOGLE一下，才看到原来你们又进行了如此精彩的评论，让我学习了很多，谢谢你们：
--------------------------------------
另外to: blue_zyb

在redleaves(程序员)回复中：
问题是这句
extern char main;
这句肯定会造成符号重定义.当然,gcc这个变态支持这么写....

我原先以为redleaves(程序员)说的造成符号的重定义指的是"语言本身相关"的重定义，所以我后来回复他说，extern char main并不会造成符号的重定义。但后来我明白了，他所说的“符号重定义”指的是定义了两个同名不同意的"符号".这里的符号只是目标文件里的一个名称.和它是不是变量的声明/定义没有关系.

于是就有了我的回复：
谢谢您的指导，昨天想当然认为extern char main，只是声明了一个变量，所以就认为不会造成符号的重定义，我知道我错了。其实会生成一个extern 符号，也就是未定义的全局变量，是一个弱符号。所以链接的时候选择了main函数的这个强符号。

我这里指的弱符号，我的理解是这样的，extern char main声明了一个外部符号，而这个外部符号并没有初始化，所以我就按照：CS:APP中提到的弱符号的定义：未初始化的全局变量是一个弱符号，我就认为这个main是一个弱符号，然后再根据书中指出的强弱符号的三条Rules，判断链接器在看到main符号的时候，选择了函数main这个强符号，然后根据晨星老大提到的链接时的符号解析步骤，得出int(main)=0x55

--------------------------------------------------------------------
原先我以为整个过程就是这样的了，可是当我看到redleaves的回复：
至于C++中，由于有了name-mangling，就可以知道每一个变量(准确点说是对象)的类型，所以出现上述这种情形时，可以分辨出来。

我又迷糊起来了，到底放入符号表的符号是原始的main符号还是经过name-mangling的符号呢？
如果是原始的符号，那么name-mangling又有什么作用呢？
那如果是经过name-mangling后的符号，那么这char main与int main()这两个符号就是在符号表中表现出来的就是不相同的两个符号了，那么当看到语句cout<<hex<<int(main)<<endl时，它又是如何对main解析的呢？

谢谢你们的指导啊，我对这些一知半解的，如何有什么错误的，请指出来，我会改正的：

昨天就回了的.不过CSDN老出问题,数据库访问出错....

C++编译器放入对象文件的是经过name-mangling的符号.就你的这个问题而言,如果char main和int main()在不同的编译单元里,你就可以看出来,会产生符号未定义的错误.
在同一个编译单元里,原本应该编译出错的,但gcc通过了.这个符号是在编译时就解析了的,完全可以做到和name-mangling无关.因为编译时可做的工作远远多于链接时.而且就算是name-mangling过的符号,也可以反解析出来.至于如何实现,没有标准,自己想怎么做就怎么做.我猜测它是按旧C的方式来处理这个问题了.

我快晕死了...

我刚在mingw上测试，发现只有lz的特殊情况不会报错（也就是只有对main函数不出错)
而对于

void fun()
{
extern char fun;
cout<<hex<<int(main)<<endl;
}
就会报错

不知道lz的gcc上如何??

应该是这样的吧?
void fun();

int main(int argc, char *argv[])
{
    //extern char main;
    //cout<<hex<<int(main)<<endl;
    fun();
    system("PAUSE");
    return EXIT_SUCCESS;
}
void fun()
{
extern char main;
cout<<hex<<int(main)<<endl;
}
我这里显示正常啊,还是55.呵呵

对了TO:redleaves(程序员),blue_zyb() 
有没有哪本书,或者哪些资料讲编译,链接的过程讲的比较详细的啊.我找了一下,好像找不到啊.真是太复杂了, 这个编译器啊.

我不是这个意思：

int main()
{
    extern char main;   
    cout<<hex<<int(main)<<endl;

    return 0;
}
不出错对吧

但是这样就会出错：
void fun()
{
extern char fun;
cout<<hex<<int(fun)<<endl;
}

int main()
{
fun();
return 0;
}

照理说fun和main应该处于对等地位，要对一起对，要错一起错，这里却给了main特殊待遇...
至少在我的mingw g++上是如此，lz再试下上面我提供的fun例子

绝大多数的书不会讲这些细节的,而且不同的编译器,实现的细节也是不一样的,千差万别.
说实在,我自己以前也是边写边想的.反正只要能达到最终目的(完成标准的要求)就可以了.只要原理上明白就行,细节就自己发挥吧.

to :blue_zyb()

是啊，我也晕了，不过这样子出错更好，就相当于只声明了一个变量，没有定义，出错更符号情理
int main()
{
extern char fun;
cout<<hex<<int(fun)<<endl;
return 0;
}

另外VC6. VC7都是链接出现错误，也再次证明了redleaves(程序员)的观点，GCC是一个变态的编译器不管里面这边复杂的细节了.真是麻烦,呵呵

另外vc7对于main的处理跟其他的任何符号也都是一样的。呵呵，所以这些各个编译器实现可能都不样的。我们讨论的这个问题，可能本身就是没有任何的意义的 =_=!

另外VC6. VC7都是链接出现错误
----------------------------
lz，应该是编译出错吧。。。

int main()
{
extern char fun;
cout<<hex<<int(fun)<<endl;
return 0;
}这个是链接出错
----------------------------
而
int main()
{
extern char main;
cout<<hex<<int(main)<<endl;
return 0;
}
是编译出错,呵呵.而我觉的编译正确,而链接出错更合理一些啊.这跟上面的那个有什么区别嘛..晕:

到底编译器主要做了哪些工作啊.两位给俺讲一讲好么?

int main()
{
extern char main;
cout<<hex<<int(main)<<endl;
return 0;
}
------------------------------
我也晕，我以为你上面给的就是这个例子，没有细看你把main弄成fun了

简单的说，就是int main（）引入了一个函数符号main，而extern char main在相同的可见域又引入了一个不同类型的char main;出现了冲突和歧异;也就是在extern char main;后面如果出现对main符号的引用，就不知道到底是指main函数还是char main了。

嗯...到此为止吧.谢谢你们两个.呵呵

to:blue_zyb()不好意思啊.过早结贴了.没分给你了..呵呵

靠.搞到现在出现:

随便建立一个空的工程,链接都会出错 

提示:文件名 目录名或卷标语法不正确

见鬼了