移植旧代码时如何处理类名冲突？答案

【问题标题】：How to handle a class name conflict when porting old code?移植旧代码时如何处理类名冲突？
【发布时间】：2010-09-16 10:30:05
【问题描述】：

我正在尝试将旧库（据我所知不使用命名空间）移植到现代编译器。我的目标之一无法区分 System::TObject 和 ::TObject （没有命名空间）。 System::TObject 是编译器原生的。

我尝试了 using 指令，即 using ::TObject;

但这并没有。

显而易见的解决方案是将所有原始库包装在一个命名空间中，然后通过名称调用它——这样可以避免歧义。但这是最明智的解决方案吗？还有其他解决方案吗？添加命名空间需要更改一堆文件，我不知道以后会不会产生不必要的影响。

【问题讨论】：

标签： c++ namespaces ambiguity

【解决方案1】：

您可以按照 Dib 的建议进行操作，稍作修改：

// In a wrapper header, eg: include_oldlib.h...

namespace oldlib
{
   #include "oldlib.h"
};

#ifndef DONT_AUTO_INCLUDE_OLD_NAMESPACE
using namespace oldlib;
#endif

这允许您仅在发生冲突的文件中#define 排除项，否则将所有符号用作全局符号。

【讨论】：

【解决方案2】：

您可以为所有旧函数制作一个包装器，并将它们打包到一个 DLL 或静态库中。

【讨论】：

【解决方案3】：

如果您有库的源代码，则可能在每个源代码的顶部包含一个头文件，其中该头文件只有：

#define TObject TMadeUpNameObject

【讨论】：

【解决方案4】：

试试这个：

namespace oldlib
{
   #inclcude "oldlib.h"
};

【讨论】：

这将导致编译器创建以oldlib为前缀的符号，这些符号不会出现在旧库中，从而导致unresolved external symbol "public: __thiscall oldlib::A::~A(void)" (??1A@oldlib@@QAE@XZ)

【解决方案5】：

我过去在封装包含与代码冲突的类的第三方头文件时使用了以下内容：

#ifdef Symbol
#undef Symbol
#define Symbol ThirdPartySymbol
#endif
#include <third_party_header.h>
#undef Symbol

这样，标题中的“符号”以 ThirdParty 为前缀，这不会与我的代码冲突。

【讨论】：