C++语言的创建初衷是“a better C”，但是这并不意味着C++中类似C语言的全局变量和函数所采用的编译和连接方式与C语言完全相同。作为一种欲与C兼容的语言，C++保留了一部分过程 式语言的特点（被世人称为“不彻底地面向对象”），因而它可以定义不属于任何类的全局变量和函数。但是，C++毕竟是一种面向对象的程序设计语言，为了支 持函数的重载，C++对全局函数的处理方式与C有明显的不同。
　　2.从标准头文件说起

　　某企业曾经给出如下的一道面试题：

　　面试题
　　为什么标准头文件都有类似以下的结构？

#ifndef __INCvxWorksh
#define __INCvxWorksh
#ifdef __cplusplus
extern "C" {
#endif
/*...*/
#ifdef __cplusplus
}
#endif
#endif /* __INCvxWorksh */

　　分析
　　显然，头文件中的编译宏“#ifndef __INCvxWorksh、#define __INCvxWorksh、#endif” 的作用是防止该头文件被重复引用。

　　那么

#ifdef __cplusplus
extern "C" {
#endif
#ifdef __cplusplus
}
#endif

　　的作用又是什么呢？我们将在下文一一道来。
 
　　3.深层揭密extern "C"

　　extern "C" 包含双重含义，从字面上即可得到：首先，被它修饰的目标是“extern”的；其次，被它修饰的目标是“C”的。让我们来详细解读这两重含义。

　　被extern "C"限定的函数或变量是extern类型的；

　　extern是C/C++语言中表明函数和全局变量作用范围（可见性）的关键字，该关键字告诉编译器，其声明的函数和变量可以在本模块或其它模块中使用。记住，下列语句：

　　extern int a;

　　仅仅是一个变量的声明，其并不是在定义变量a，并未为a分配内存空间。变量a在所有模块中作为一种全局变量只能被定义一次，否则会出现连接错误。

　　通常，在模块的头文件中对本模块提供给其它模块引用的函数和全局变量以关键字extern声明。例如，如果模块B欲引用该模块A中定义的全局变 量和函数时只需包含模块A的头文件即可。这样，模块B中调用模块A中的函数时，在编译阶段，模块B虽然找不到该函数，但是并不会报错；它会在连接阶段中从 模块A编译生成的目标代码中找到此函数。

　　与extern对应的关键字是static，被它修饰的全局变量和函数只能在本模块中使用。因此，一个函数或变量只可能被本模块使用时，其不可能被extern “C”修饰。

　　被extern "C"修饰的变量和函数是按照C语言方式编译和连接的；

　　未加extern “C”声明时的编译方式

　　首先看看C++中对类似C的函数是怎样编译的。

　　作为一种面向对象的语言，C++支持函数重载，而过程式语言C则不支持。函数被C++编译后在符号库中的名字与C语言的不同。例如，假设某个函数的原型为：

void foo( int x, int y );

　　该函数被C编译器编译后在符号库中的名字为_foo，而C++编译器则会产生像_foo_int_int之类的名字（不同的编译器可能生成的名字不同，但是都采用了相同的机制，生成的新名字称为“mangled name”）。

　　_foo_int_int这样的名字包含了函数名、函数参数数量及类型信息，C++就是靠这种机制来实现函数重载的。例如，在C++中，函数 void foo( int x, int y )与void foo( int x, float y )编译生成的符号是不相同的，后者为_foo_int_float。
　　同样地，C++中的变量除支持局部变量外，还支持类成员变量和全局变量。 用户所编写程序的类成员变量可能与全局变量同名，我们以"."来区分。而本质上，编译器在进行编译时，与函数的处理相似，也为类中的变量取了一个独一无二 的名字，这个名字与用户程序中同名的全局变量名字不同。

　　未加extern "C"声明时的连接方式

　　假设在C++中，模块A的头文件如下：

// 模块A头文件　moduleA.h
#ifndef MODULE_A_H
#define MODULE_A_H
int foo( int x, int y );
#endif

　　在模块B中引用该函数：

// 模块B实现文件　moduleB.cpp
#include "moduleA.h"
foo(2,3);

　　实际上，在连接阶段，连接器会从模块A生成的目标文件moduleA.obj中寻找_foo_int_int这样的符号！

　　加extern "C"声明后的编译和连接方式

　　加extern "C"声明后，模块A的头文件变为：

// 模块A头文件　moduleA.h
#ifndef MODULE_A_H
#define MODULE_A_H
extern "C" int foo( int x, int y );
#endif

　　在模块B的实现文件中仍然调用foo( 2,3 )，其结果是：

　　（1）模块A编译生成foo的目标代码时，没有对其名字进行特殊处理，采用了C语言的方式；

　　（2）连接器在为模块B的目标代码寻找foo(2,3)调用时，寻找的是未经修改的符号名_foo。

　　如果在模块A中函数声明了foo为extern "C"类型，而模块B中包含的是extern int foo( int x, int y ) ，则模块B找不到模块A中的函数；反之亦然。

　　所以，可以用一句话概括extern “C”这个声明的真实目的（任何语言中的任何语法特性的诞生都不是随意而为的，来源于真实世界的需求驱动。我们在思考问题时，不能只停留在这个语言是怎么 做的，还要问一问它为什么要这么做，动机是什么，这样我们可以更深入地理解许多问题）：
　　实现C++与C及其它语言的混合编程。
　　明白了C++中extern "C"的设立动机，我们下面来具体分析extern "C"通常的使用技巧。
　　4.extern "C"的惯用法

　　（1）在C++中引用C语言中的函数和变量，在包含C语言头文件（假设为cExample.h）时，需进行下列处理：

extern "C"
{
#include "cExample.h"
}

　　而在C语言的头文件中，对其外部函数只能指定为extern类型，C语言中不支持extern "C"声明，在.c文件中包含了extern "C"时会出现编译语法错误。

　　笔者编写的C++引用C函数例子工程中包含的三个文件的源代码如下：

/* c语言头文件：cExample.h */
#ifndef C_EXAMPLE_H
#define C_EXAMPLE_H
extern int add(int x,int y);   // "extern" is optional [Zero]
#endif
/* c语言实现文件：cExample.c */
#include "cExample.h"
int add( int x, int y )
{
return x + y;
}
// c++实现文件，调用add：cppFile.cpp

/*

[Zero] below, can be written as

extern "C" int add(int,int);

#include "cExample.h"

*/

extern "C" 
{
#include "cExample.h"
}
int main(int argc, char* argv[])
{
add(2,3);
return 0;
}

　　如果C++调用一个C语言编写的.DLL时，当包括.DLL的头文件或声明接口函数时，应加extern "C" {　}。

　　（2）在C中引用C++语言中的函数和变量时，C++的头文件需添加extern "C"，但是在C语言中不能直接引用声明了extern "C"的该头文件，应该仅将C文件中将C++中定义的extern "C"函数声明为extern类型。
　　笔者编写的C引用C++函数例子工程中包含的三个文件的源代码如下：

//C++头文件 cppExample.h
#ifndef CPP_EXAMPLE_H
#define CPP_EXAMPLE_H
extern "C" int add( int x, int y );
#endif
//C++实现文件 cppExample.cpp
#include "cppExample.h"
int add( int x, int y )
{
return x + y;
}
/* C实现文件 cFile.c
/* 这样会编译出错：#include "cExample.h" */
extern int add( int x, int y );
int main( int argc, char* argv[] )
{
add( 2, 3 );
return 0;
}

 先看下面的测试代码(1)和(2)：
 =====================================================================

* 比较宽的知识面，并且能够时时补充自己的知识和完善自己的知识结构

* 耐心好，特别是在调试和学习阶段，世界上没有聪明的人只有刻苦的人。做开发其实就两件事情学习和改错，在这两件事情中间的开发过程其实是比较简单的

* 永远记住：代码是给人看的而不是给机器运行的，计算机在执行程序时是不怕累的，而人在看代码时是非常累的

* 良好的编码习惯，至少保证自己能够随时看懂几个月前自己所写的代码

* 尽量让你的代码能够很容易的被别人理解，写代码时想想你会不会在两个月后被别人骂

* 不要容忍自己犯重复的错误和写重复的代码

* 知道如何做比得到代码更重要

* 尽量不要做已经有很多人已经做过的事情

* 学会尊重别人的开发成果，除非不得已不要下决定全面替换以前的系统

* 珍惜自己的时间与工作成果，尽量让别人分享自己的开发成果

* 避免假设，多思考极端情况与引起错误的可能性，努力减少低级错误

* 不要相信至少是不要轻信自己为自己所做的测试结果

* 懂得坚持自己的开发思路，并懂得理解与吸收别人的思想

* 学会与其他人保持一致，但不能放弃自己的开发特色

* 懂得向你周围的人学习，不论是开发能力上的还是开发经验上的

* 懂得软件结构的的重要性，分析代码前先分析代码的结构

* 学会总结，定期总结自己所学会的知识，看看自己前段时间因为各种原因所浪费的时间

* 学会计划，尽量不要认为通过延长自己的工作时间来完成任务

* 学会正确估计自己的能力和工作时间

下面这些是我认为一些比较适合我自己的方面，不一定对每个人都合适：

* 多看些杂志，没事情的时候可以看看以前看过的参考书，书中很可能有你以前没有注意到的一些细节

* 不要太早去做一些与开发无关的事情，因为学习的黄金时期是很短暂的

* 学会分析别人的系统，多看看别人所开发的系统的先进的一面。这里包括别人的开发思路，实现时所采用的结构

* 时常感到自己将被淘汰，经常埋怨自己的不努力

* 知道自己缺少什么

* 强迫自己做一些自己不喜欢做的事情，比如说写文档

* 能够有勇气重写自己所开发的系统，但当你重做时你应该采取和前一次不同的工作方式和方法，否则重做就没有必要

* 将问题简单化而不是复杂化

* 将维护时会产生的一部分问题转移到开发时或是设计时来解决

* 有时候也不妨问问自己：我不做开发时去做什么

* 坚持为自己做每周的开发计划，在事情没有做完以前不要轻易转移自己的注意力

* 尽可能多的将你所做的教给别人，因为你有一天可能不再负责这个系统

* 做事一定要有始有终，除非是有不得已的理由否则不要在工作完成前提前离开

* 不要将你为公司做的东西带走，你因该带走的是开发经验和对开发的认识而不是代码和产品

* 感到累时就休息一下，给自己放个假也无妨，毕竟人不是机器

   认真考虑一下，得到最有天赋的项目开发人员的最佳方法是培养，而非购买。

　　在阅读有关敏捷开发的材料时，我发现，无论是传统的软件开发技术，还是敏捷方法，都要高度依赖熟练的开发人员才能确保成功。这一事实让我触动。由于许多因素的影响，具有相似经历的开发人员的表现水平却相差很大，这点已为人们所接受；所以人们对优秀的开发人员比较关注也就不足为奇了。尽管如此，一个或一小群开发人员，利用“英雄模式”开发，通过他们的奉献精神与坚韧毅力，还是完成了许多开发工作。

　　很明显，我们需要优秀的开发人员。但问题是，到哪去找优秀的开发人员呢？

　　十几年来我一直参与招聘工作，我可以毫不迟疑地告诉你：有可能找到最优秀的开发人员，但是可能性不大。这不是一件容易的事，即使读完一千份简历，可能也只能找到一两个真正优秀的开发人员。

　　认真考虑一下，你会发现，只有通过培养，而不是购买，才能得到最优秀的开发人员。

　　什么造就最优秀的开发人员？

　　关于是什么造就最优秀的开发人员，大家持不同的看法。不管是敏捷还是传统的开发技巧都需要开发人员拥有稍异于人的东西。但是，无论开发人员应用哪种技巧，这都归结为一个词：思考。

　　位于Bloom认知技能教育目标分类最底层的是知识。即回想（或识别）数据与信息。应用在开发方面，这就意味着识别C#语法或回想出执行循环的正确语法。

　　位于认知分类最顶层的是综合与评估。综合指能够合成不同的因素以形成全新的解决方案。而评估是指对观念、方法或材料做出判断的能力。在工作过程中，开发人员需要不断地应用这些高层次的认知能力。

　　许多人认为，与描述认知过程的差异相比，将这一观念表达为思考更为自然。通常，对高层次的观念（例如如何综合片段来形成解决方案）所做的思考越多，开发人员就更优秀。

　　海底捞针

　　在完全放弃招聘（购买）最优秀的开发人员之前，我们先通过检验专业技能来了解一下招聘过程。我例行公事地对应聘开发职位的候选人进行了一次口头测试。由于我面试的大多数开发人员需要能够熟练地操作数据库，我问他们一个简单的问题：

　　给你一个带客户id域与名称的客户表，以及一个带序号id，客户id与其它细节的序号索引表，用什么查询可返回不带序号的客户表？

　　此问题的答案需要应用外部连接（outer join）知识。（在SQL-87语法中，你可以应用*=，但这一答案正日益少见。）我的非正式统计表明，答对此问题的人数在10%以下。平均来说，我面试的开发人员拥有大专学历，有1到2年的工作经验。但是，据我的观察，多年的工作经验与他们是否答对此问题关系不大。

　　对我而言，无力回答此问题表明开发人员并不完全了解SQL所要求的以集合为基础的逻辑方式。我认为这是一个优秀开发人员的基本技能。

　　另一个问题更有趣，因为它没有正确答案：

　　 你最喜欢微软.NET中的哪项功能？

　　明显地，你可以在这个问题中插入任何技术。问题的答案可以清楚地告诉你开发人员的思考方向。如果它告诉我是IntelliSense（帮助你记忆对象与方法界面的Visual Studio功能），我就知道他们主要关心如何将代码加入编辑器，这并不是优秀开发人员的思考方式。顺便说一下，如果他们给出那个答案，他们可获得“加击”。（另一击？即“你还喜欢哪项功能？”）

　　我在寻找一类表明他们正在思考文本编辑框以外的事情的答案。我在寻找这样的答案：“因为运行时间类型的信息，可编写灵活代码的能力。”这样的答案表明他们对工作进行了深入思考，这是成为最优秀的开发人员的基本条件。

　　“你最不喜欢什么？”这个问题同样富于启示。“忘记C#中的分号”这样的答案让我怀疑候选开发人员是否达到正确的思考层次。“无力有效应用垃圾收集器”这样的答案表明他们既不了解平台的需要，也缺乏处理复杂问题的经验。

　　问题“你最喜欢/不喜欢什么？”的回答比SQL问题的回答要好得多，但仍然并不乐观。参加面试的开发人员，超过70%回答的是琐碎的问题，其它10%左右的答案表明他们要么编码的水平不高，要么缺乏高层次的思考。

　　最终的结果表明，要找到最优秀的开发人员几乎是不可能的事情。实际上，我也可能只招聘到2到3个可称之为最佳开发人员的人。

　　 培养优秀的开发人员

　　找到有潜质，即好奇心强、个性好学的开发人员要更容易一些。这些开发人员确实希望在自己与他人的生活中发挥重要的作用。他们可能并不了解关系数据库，但他们乐于学习。他们带来学习的热情，让周围的人充满活力。

　　在许多机构，这种热情却以服从的名义受到压制。“我们一样那样做”的心态打消了任何改善状况的尝试。因此，开发人员常常感到困惑。因为组织一方面声明希望组建世界级的开发团队（每个组织都希望拥有这样的团队）；另一方面，他们又不愿意做出变革。

　　但是，我们可以采取行动，以保证新开发人员的干劲与期望不会受到压制。以下是我就培养优秀开发人员提出的一些建议：

　　指导：指定一个导师来帮助开发人员。这个人必须是一个资深开发人员，开发权威或关心团队和进程改善、乐于助人的构架师。这个人不应是开发人员的直接领导或经理（如果可能的话）。指导交谈应该以开发人员，而不是组织的需求为中心。

　　代码审查：代码审查是提高开发能力的有效手段。但很多组织却极少这样做。另外，人们很少把它当作是学习机会，而把它当作贬低开发人员的时机。请进行代码审查，把它当作培训与教育，而非压制的手段。

　　渐进体验：向开发人员提供增量分配来鼓励他们不断成长。由于我们无法控制将来的项目，这可能是最难以执行的方法。但是，提供尽可能多的渐进分配结构将会取得长期回报。

　　学习挑战：除了渐进分配以外，还要找出其它方式激励开发人员学习尽可能多的知识，即使这些知识不能立即起作用。例如，如果你有一家网络开发商店，鼓励开发人员学习智能客户（Smart Client）技术，以帮助开发人员养成学习习惯。

　　内部培养

　　尽管你想为下一个项目找到优秀的开发人员，但优秀的开发人员并不容易找到。项目的成功主要还是依靠现在团队里的开发人员。他们越优秀，你成功的机会就越大。找到技术熟练的可靠人才来完成你的需求肯定会很困难。自己培养开发人员，是获得你所需要的开发人员唯一现实的方法。

自定义的类从某种意义上来讲，也是一种用户自定义的数据，形如struct。
基于此考虑，完全可以从非MFC扩展DLL中导入非MFC的用户自定义的类。

方案如下：
1) 首先建立一个DLL( WIN32 DLL)工程，创建头文件*.dll，自定义一个类，
在类的前面添加"__declspec(dllexport)"关键字，表示该工程到处这个类。
例如: class __declspec(dllexport) myClass ...

2) 在其实现文件中，添加头文件"#include "*.h""，并实现相应的类实现部分。

3) 编译执行生成*.dll文件，将其COPY到应用测试工程的执行目录下(debug/release)
下，COPY DLL工程的头文件*.h到应用测试工程的目录下，添加进项目中，并将其中的
"__declspec(dllexport)"修改为"__declspec(dllimport)"。

4) 在其实现文件中添加头文件"#include "*.h""，然后对其导入的类进行相应的操作。

5) 编译运行测试程序，便可以实现类相关的操作。

NOTE: 对于静态/动态链接到MFC的规则DLL也可以达到同样的效果，导入自定义的类。

1．  将 scbarg.h ， scbarg.cpp ， sizecbar.h ， sizecbar.cpp ， mybar.h ， mybar.cpp 文件 copy 到你的工程目录下，打开 vc ，将这几个文件添加进工程。

2．  打开 stdafx.h 文件，在其中加入： #include "sizecbar.h" ， #include "scbarg.h" 。

3．  为 CmainFrame 类添加成员变量： CMyBar        m_wndMyBar 。

4．  重载 CMainFrame::DestroyWindow() ，在其中加入

       CString sProfile(_T("BarState"));

       m_wndMyBar.SaveState(sProfile);

SaveBarState(sProfile);

5．  修改 CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct) 如下：

int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)

{

       if (CFrameWnd::OnCreate(lpCreateStruct) == -1)

              return -1;

       if (!m_wndToolBar.CreateEx(this, TBSTYLE_FLAT, WS_CHILD | WS_VISIBLE | CBRS_TOP

              | CBRS_GRIPPER | CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC) ||

              !m_wndToolBar.LoadToolBar(IDR_MAINFRAME))

       {

              TRACE0("Failed to create toolbar\n");

              return -1;      // fail to create

       }

       if (!m_wndStatusBar.Create(this) ||

              !m_wndStatusBar.SetIndicators(indicators,

                sizeof(indicators)/sizeof(UINT)))

       {

              TRACE0("Failed to create status bar\n");

              return -1;      // fail to create

       }

       if (!m_wndMyBar.Create(_T("My Bar"), this, 123))

       {

           TRACE0("Failed to create mybar\n");

           return -1;      // fail to create

       }

       // TODO: Delete these three lines if you don't want the toolbar to

       //  be dockable

       m_wndMyBar.SetBarStyle(m_wndMyBar.GetBarStyle() |

       CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC);

       m_wndToolBar.EnableDocking(CBRS_ALIGN_ANY);

       m_wndMyBar.EnableDocking(CBRS_ALIGN_ANY);

       EnableDocking(CBRS_ALIGN_ANY);

       DockControlBar(&m_wndToolBar);

       DockControlBar(&m_wndMyBar, AFX_IDW_DOCKBAR_LEFT);

       CString sProfile(_T("BarState"));

       if (VerifyBarState(sProfile))

       {

           m_wndMyBar.LoadState(sProfile);

           LoadBarState(sProfile);

       }

       return 0;

}

注：红色字体部分为所加内容。

6．  在“查看”菜单下添加菜单项 mybar ，设其 id 为： ID_VIEW_MYBAR.

7．  为其添加 CMainFrame::OnViewMybar() ， CMainFrame::OnUpdateViewMybar(CCmdUI* pCmdUI) 函数，内容为：

void CMainFrame::OnViewMybar()

{

       // TODO: Add your command handler code here

       BOOL bShow = m_wndMyBar.IsVisible();

       ShowControlBar(&m_wndMyBar, !bShow, FALSE);

}

void CMainFrame::OnUpdateViewMybar(CCmdUI* pCmdUI)

{

       // TODO: Add your command update UI handler code here

       pCmdUI->Enable();

       pCmdUI->SetCheck(m_wndMyBar.IsVisible());

}

编译运行即可，如果你想改变 workshop 中的 cedit 成员变量（如本例 workshop 中的树），只需改变 mybar 中的代码即可。
下载连接：CMyBar.rar(http://www.cppblog.com/zerolee/admin/Files.aspx)