回头看一看string类的例子（为了方便在这里重复这个例子）：

//文件excelSoftCompany.h
namespace excelSoftCompany 
{   
  class string {/*..*/};
  class vector {/*..*/};
}

现在可以在同样的程序中像标准的string一样来使用自己的string，看下面的代码：

#include  //  std::string
#include "excelSoftCompany.h"
int main()
{
  using namespace excelSoftCompany;
  string s; //引用类excelSoftCompany::string
  std::string standardstr; //现在实例化的是一个ANSI string
  return 0;
}

命名空间可以扩展

C++标准化委员会意识到相关联的申明可以跨越好几个translation units。所以命名空间可以定义一部分。例如

  //文件proj_const.h
namespace MyProj 
{
   enum NetProtocols
  {
      TCP_IP,
      HTTP,
      UDP
  };  // enum
}
  //文件proj_classes.h
namespace MyProj
{ // 扩展了命名空间MyProj
   class RealTimeEncoder{ public: NetProtocols detect();  };
   class NetworkLink {}; //全局的
   class UserInterface {};
}

在分开的文件中，一样的命名空间可以通过附加申明扩展。

完整的命名空间MyProj可以由两个文件引出就像下面这样：

  //文件app.cpp
#include "proj_const.h"
#include "proj_classes.h"
int main() 
{
  using namespace MyProj;
  RealTimeEncoder encoder;
  NetProtocols protocol = encoder.detect();
  return 0;
} 

命名空间的别名

就像你观察到的，命名空间短的名字最终导致命名冲突。但是过长的命名空间不容易使用。为了这个目的，使用命名空间别名（namespace alias）。下面的例子为笨拙的Excel_Software_Company命名空间定义了别名ESC。命名空间的别名还有其他用途，就像你将看到的。

//文件decl.h
namespace Excel_Software_Company 
{
  class Date {/*..*/};
  class Time {/*..*/};
}
//文件calendar.cpp
#include "decl.h"
int main()
{
  namespace ESC = Excel_Software_Company; //ESC是Excel_Software_Company
                                          //的别名
  ESC::Date date;
  ESC::Time time;
  return 0;
}

Koenig查找

Andrew Koenig，C++的创建者之一，为解决命名空间成员的查找问题设计了一种算法。这种算法也叫参数依赖查找（argument dependent lookup），现在为所有适应标准的编译器用来处理下面情况：

---

警告：有些现存的编译器并不完全支持Koenig查找。因此，下面的程序——依赖于Koenig 查找——在并不完全支持ANSI/ISO标准的编译器下可能不能编译通过。

---

namespace MINE
{
  class C {};
  void func;
}
MINE::C c; //类型为MINE::C的全局对象
int main()
{
  func( c ); //OK，调用了MINE::f
  return 0;
}

在程序中既没有使用using申明也没有使用using指示。但是，编译器做了正确的事情——通过应用Koenig查找，它正确的将未加限制的func识别为在命名空间MINE中申明的函数。

Koenig查找指示编译器不仅仅在平常应该找的地方，比如局域范围内查找，还要在包含参数类型的命名空间中查找。因此接着的代码行中检查函数func()的参数对象c，c属于命名空间MINE。编译器将命名空间MINE视为在func()的申明之中，“猜”出了程序员的意图：

func( c ); // OK，调用MINE::f

没有Koenig查找的话，命名空间将给程序员不想接受的麻烦，程序员不得不重复完整名字或使用许多using申明。为了进一步将参数推给Koenig查找，考虑下面的例子：

#include
using std::cout;
int main()
{
  cout<<"hello";   //OK，通过Koenig查找运算符<<被带到了范围里面
  return 0;
}

using申明将std::cout注入main()的范围中，从而使程序员可以使用未加限制的cout。然而，你可能想起重载运算符<<不是std::cout的成员。它是在命名空间std内定义的友元函数，它接受一个std::ostream对象作为参数。没有Koenig查找，程序员不得不写成下面的形式：

std::operator<<(cout, "hello");

作为选择，程序员也可以提供using namespace std;指示。然而没有一种方法是领人赏心悦目的，因为他们使代码散乱而且是混淆和错误的源头。（using指示至少有利于使名字在当前范围可见，因为他们使得命名空间的所有成员不加区别的都可见了）。幸运的是，Koenig查找“做了正确的事情”，以文雅的方式使你从这些烦劳中解脱出来。

Koenig查找是自动使用的。激活它不需要特殊的指示或配置开关，也没有办法关闭它。必须时刻注意这个事实，因为在有些情况下它可能带来令人吃惊的结果。例如

namespace NS1
{
  class B{};
  void f;
};
void f(NS1::B); 
int main()
{
  NS1::B b;
  f;  //不明确；NS1::f()还是f(NS1::B)？
  return 0;
}

对于这种情况，适应标准的编译器一定会给出错误。但是不符合标准的编译器不会指出调用的不明确；他们简单的选择f()的一个版本。这可能是程序员不想要的结果。此外，问题可能发生在开发的后期，在工程中加入f()的附加版本的时候——可能妨碍编译器的查找算法。这种不明确不仅仅限制在全局名字。它也可能出现在两个命名空间互相有关的时候——例如，命名空间申明的类，而类被在不同命名空间申明的类成员函数作为参数。

命名空间实践

从 前面的例子中可以总结出，和语言其他特性一样必须明智的使用命名空间。对于只包含少数类和几个源文件的小工程，命名空间是不需要的。在大多数情况下，这样 的程序由一个程序员编码和维护，他们使用的组件数目有限。命名空间的可能性很小。如果还是出现了命名冲突，一般是重命名存在的类或函数，或简单的在后面增 加命名空间。

另一方面，大型工程——如前面说明的——更容易受到命名冲突的影响；因此他们需要系统的命名空间。有上百程序员合作的 工程或许多开发小组一起合作的大项目十分常见。例如Microsoft Visual C++ 6.0的开发历时18个月，超过1000的程序员与开发过程有关。管理这样的大型工程需要良好文档的编码方针——命名空间正是这样一个工具。

在大型工程利用命名空间的方针

为 了展示命名空间如何在结构管理中应用，假象一个国际信用卡公司的在线事务处理系统。项目由好几个开发小组组成。其中数据库管理小组负责创建和维护数据库的 表、索引和访问授权。数据小组也必须提供访问例程和对数据库中数据进行检索、操作的数据对象。第二个小组负责图形用户界面（GUI）。第三个小组处理来自 电影院、饭店、商店以及任何旅行者可能使用他们的国际Unicard付帐的地方提出的国际在线请求。在每个信用卡的所有者交易之前，每一个购买，电影票、 珠宝或艺术书都必须通过Unicard确认。每个确认的过程检查信用卡的有效性、它的有效期限和信用卡所有者的收支平衡。对于国内购买有一个相似的确认过 程。但是，国际确认要求用卫星传送，而国内确认一般使用电话。

在软件项目里，代码的可重用性是十分重要的。因为，同样的处理逻辑同 时适用与国内和国际确认，所以检索相关信息和执行必要计算的数据库访问对象应该是相同的。虽然如此，国际确认还需要经常使用通讯协议堆栈，以接收通过卫星 传过来的请求，解释它再返回发送者一个加密的回答。基于卫星确认的典型实现可以是将数据库访问对象和必要的通讯对象捆绑在一起，通讯对象封装了协议、通讯 层、优先权管理、消息队列、加密和解密等过程。不难想象通讯对象和数据库访问对象同时使用了一个名字而引起了命名冲突。

例如，两个对象——一个封装了数据库连接而另一个指的是卫星连接——可能有同样的名字：Connection。但是如果通讯组件和数据库访问对象申明在两个不同的命名空间中，潜在的命名冲突将减至最小。因为，com::Connection和dba::Connection可以在同一个应用程序中同时使用。系统的方法可以是给每一个小组分配一个独立的命名空间。这样的方针可以帮助你在不同的小组以及第三方代码中避免命名冲突。

命名空间和版本控制

成 功的软件项目不会只有一个版本。在大多数项目中，基于前辈的新版本不断发布。此外，前一个版本必须支持打补丁和调整以适应新的操作系统、新的应用环境和新 的硬件。Web浏览器、商业数据库、字处理软件和多媒体工具就是这样的例子。同样的开发小组必须对同一软件产品的不同版本提供支持是一种常见情况。大量的 软件能共享同样产品的不同版本，但是每一个版本也有它特殊的组件。这种情况下可以使用命名空间别名迅速从一个版本切换到另一个版本。

一般连续项目有一些经常使用的基础软件组件。另外，每一个版本有自己独有的特殊组件。命名空间别名可以提供动态命名空间（dynamic namespaces）；命名空间别名可以指给定时间的版本X的命名空间，在其他时候、它也可以指不同的命名空间。例如

namespace ver_3_11  //16 bit
{  
  class Winsock{/*..*/};
  class FileSystem{/*..*/};
};
namespace ver_95 //32 bit
{  
  class Winsock{/*..*/};
  class FileSystem{/*..*/};
}
int main()//实现16 bit版
{ 
  namespace current = ver_3_11; //current是 ver_3_11的别名
  using current::Winsock;
  using current::FileSystem;
  FileSystem  fs; // ver_3_11::FileSystem
  //...
  return 0;
}

在这个例子中，别名current是一个可以指ver_3_11也可以指ver_95的符号。为了在不同版本之间切换，程序员仅仅只需要将不同的命名空间赋值给它。

命名空间不会带来额外的开销

命名空间的实现包括Koenig查找都是静态的。命名空间的底层实现使用名字分裂（name mangling），就是编译器通过函数的参数列表，函数的类名以及函数的命名空间名字来合成出函数的独一无二的名字（参见第十三章“C语言的兼容性问题”，有名字分裂的具体细节）。因此，命名空间不会成生运行时间和内存的开销。

命名空间和语言其他特性的互相影响

命名空间和语言的其他特性结合影响了程序设计技术。命名空间使得C++中的有些特性变的可有可无或是不受欢迎。

不需用范围运算符来指定全局变量

在一些frameworks（例如MFC），它习惯于加范围运算符到全局函数前面来显式的指明，这是全局函数而非类成员函数（象下面的例子那样）：

void String::operator = (const String& other)
{
  ::strcpy (this->buffer, other.getBuff()); 
}

这种习惯使不推荐的。许多曾经是全局函数的标准函数现在都被归到命名空间内部了。例如，现在strcpy属于命名空间std，大多数标准库的函数都是如此。前面那些有范围运算符的函数可能使编译器的查找算法混淆；另外，这样做破坏了分割全局命名空间的思想。因此，不推荐你在函数名之前加上范围运算符。

将外部函数变为文件内函数

在标准C中，没有申明为静态的非局域变量有内部连接（internal linkage），这意味着仅仅在同一translation unit中申明的才是可见的（参见第二章“标准简报：ANSI/ISO C++的最新附加部分”）。这种技术用于信息隐藏（如下面的例子）：

    //File hidden.c
static void decipher(FILE *f); //仅仅在本文件中可见
    //现在在当前源文件中使用该函数
decipher ("passwords.bin");
    //文件结束

尽管在C++中仍然支持这样，这个习惯现在已成为了反对的特性（deprecated feature）。你编译器未来的版本中，编译器在找到非类成员函数的静态标识符时可能会给出警告。为了使函数只在自己的translation unit中可见，使用未命名命名空间（unnamed namespace）。下面的例子示范了这种用法：

//File hidden.cpp
namespace        //未命名
{
  void decipher(FILE *f);  //仅仅在本文件中可见
}
  //现在在当前文件中使用函数
  //不需要使用命名空间申明或命名空间指示
decipher ("passwords.bin");

尽 管在未命名命名空间中的名字可能需要外部连接（external linkage），他们在其他translation unit中却不可见；产生的效果是在未命名命名空间出现的名字有静态连接（static linkage）。如果你在其他文件的未命名命名空间中申明同名的其他函数，两个函数互相隐藏，把他们不会产生命名冲突。

标准头文件

现在所有的标准C++头文件必须这样包括：

#include  //注意：没有“.h”扩展

.h扩展被忽略了。标准C头文件也服从这个习惯，只是有一个附加的字母c。因此，以前叫的C头文件现在叫。例如

#include  //以前： 注意前缀'c' 和//忽略".h"

C头文件的旧的习惯，仍然被支持；但是，是被反对的特性，因此在新的C++代码中不使用。原因是C 头文件将其申明的名字加入到了全局命名空间中。然而在C++中，大多数标准申明归到了命名空间std中，像这样的标准C头文件一样。不能从在头文件的物理地址使用的实际命名习惯或它的实际名字得出什么推论。事实上，大多数编译器为和对应的符号共享一个物理文件。通过一些隐藏的预处理技巧很容易办到。记住你必须使用using申明、using指示或完整名字来访问新风格标准头文件中的申明。例如

#include 
using namespace std;  
void f()
{
    printf ("Hello World/n");
}

命名空间的限制

C++标准给命名空间的使用定义了几条限制。这些限制式为了有意避开可能搞得一团糟的不规则和不明确的地方。

不能改变命名空间std

一般的命名空间是开放的，所以通过交叉在许多文件中的附加申明和定义可以完全合法的扩展命名空间。唯一的例外是命名空间std。根据标准，通过附加申明改变命名空间std的结果——不要动已存在地那个——是为定义的行为，也是不允许的。这条限制可能很武断，但是它只是公共的认识——任何篡改命名空间std的行为破坏了标准申明在专有排外的命名空间中的基本观念。

用户定义的new和delete不能在命名空间中申明

标准禁止在命名空间中申明new和delete运算符。下面的例子说明了为什么：

char *pc; //全局
namespace A
{
  void* operator new ( std::size_t );
  void operator delete ( void * );
  void func ()
  {
    pc = new char ( 'a'); //使用A::new
  }
} //A
void f() { delete pc; } //调用A::delete还是//::delete？

有些程序员可能希望选中运算符A::delete，因为它匹配用来分配内存的new运算符；另一些程序员可能希望选中标准运算符delete，因为A::delete对于函数f()是不可见的。通过禁止在命名空间中申明运算符new和delete，C++避免了这样的麻烦。

总结

命名空间是最新加入C++标准的。因此，有些编译器不完全支持这些特性。不过，所有的编译器厂商将在将来的版本中完全支持命名空间。不必过分强调命名空间的重要性。如你所见，许多著名的C++程序使用了STL的组件、iostream库和其他标准头文件——所有这些都是命名空间的成员。

大型软件项目可以明智的使用命名空间来避免公共缺陷和使得版本控制更容易，就像你已经看到的。

C++提供三种方法，将命名空间的要素加入到当前的范围中。第一种是使用using指示，它将使命名空间的所有成员在当前范围中可见。第二种是使用using申明，它将更有选择性的使命名空间中的单一组件可见。最后一种使用独一无二的完整名字来标志命名空间成员。另外，依赖参数查找或Koenig lookup，不必强迫程序员提及命名空间就可以捕捉程序员的正确意图。

---

© Copyright 1999, Macmillan Computer Publishing. All
rights reserved.