extern "C"
为什么需要使用extern "C"呢？C++之父在设计C++之时，考虑到当时已经存在了大量的C代码，为了支持原来的C代码和已经写好C库，需要在C++中尽可能的支持C，而extern "C"就是其中的一个策略。
试想这样的情况:一个库文件已经用C写好了而且运行得很良好，这个时候我们需要使用这个库文件，但是我们需要使用C++来写这个新的代码。如果这个代码使用的是C++的方式链接这个C库文件的话，那么就会出现链接错误.我们来看一段代码:首先，我们使用C的处理方式来写一个函数，也就是说假设这个函数当时是用C写成的:
//f1.c
extern "C"
{
void f1()
{
return;
}
}
编译命令是:gcc -c f1.c -o f1.o 产生了一个叫f1.o的库文件。再写一段代码调用这个f1函数:
// test.cxx
//这个extern表示f1函数在别的地方定义，这样可以通过
//编译，但是链接的时候还是需要
//链接上原来的库文件.
extern void f1();
int main()
{
f1();
return 0;
}
通过gcc -c test.cxx -o test.o 产生一个叫test.o的文件。然后，我们使用gcc test.o f1.o来链接两个文件，可是出错了，错误的提示是:
test.o(.text + 0x1f):test.cxx: undefine reference to 'f1()'
也就是说，在编译test.cxx的时候编译器是使用C++的方式来处理f1()函数的，但是实际上链接的库文件却是用C的方式来处理函数的，所以就会出现链接过不去的错误:因为链接器找不到函数。
因此，为了在C++代码中调用用C写成的库文件，就需要用extern "C"来告诉编译器:这是一个用C写成的库文件，请用C的方式来链接它们。
比如，现在我们有了一个C库文件，它的头文件是f.h，产生的lib文件是f.lib，那么我们如果要在C++中使用这个库文件，我们需要这样写:
extern "C"
{
#include "f.h"
}
回到上面的问题，如果要改正链接错误，我们需要这样子改写test.cxx:
extern "C"
{
extern void f1();
}
int main()
{
f1();
return 0;
}
重新编译并且链接就可以过去了.
总结
C和C++对函数的处理方式是不同的.extern "C"是使C++能够调用C写作的库文件的一个手段，如果要对编译器提示使用C的方式来处理函数的话，那么就要使用extern "C"来说明。
本文转自：http://www.diybl.com/course/3_program/c++/cppsl/2008810/135631.html
相关文档：
这一系列文章是我构建C/C++插件开发框架开放框架的过程。后面会一直更新，直至构建完成。
《构建自己的C/C++插件开发框架（一）——初步设想》
《构建自己的C/C++插件开发框架（二）——总体功能》
《
构建自己的C/C++插件开发框架（三）——总体结构
》
《构建自己的C/C++插件开发框� ......
最近一个朋友准备把C代码在ECLIPSE上编译，以前一直搞的JAVA，也知道ECLIPSE支持C工程，但是自己从来没搞过，所以就自己先从网络上找资料，主要方法如下
1、安装JDK和Eclipse
这里就不多说，具体请见：http://blog.chinaunix.net/u/16292/showart_223309.html
我的安装环境是jdk1.5，eclipse3.2.1
2、安装C++的E ......
用c语言做了个通讯录，系统一运行时便将数据文件加载进内存，并用链表存储。退出系统时，自动将链表中的所有节点再存入文件。
可是现在，每次退出系统，文件里都会比链表多存储一条记录。
如：现在只有两条记录，退出后在启动时一查询，就会多一条乱记录（系统自己加的）。
加载文件的部分代码如下：
/*判断文件是否 ......
VC中下面几个结构体大小分别是多少呢
struct MyStruct
{
double m4;
char m1;
int m3；
};
struct MyStruct {
char m1;
double m4;
int m3;
};
#pragma pack(push) ......
以前曾经总结过一篇(http://www.cppblog.com/franksunny/archive/2007/11/29/37510.html
)，关于在
C
中如何调用
C++
的代码，当时并未做完全的展开，只是简单的做了下调试，最近看到一个题目要求实现
C
和
C++
中代码的互相调用，其结果虽然都是通过
extern “C”
来实现
，但是具体还是有些差别的� ......
