修改装饰名称 - VS6.0到VS2005的迁移

Question

经过几个小时的谷歌搜索，我认为是时候问专家了。我们有一个遗留模块（MS Visual C ++ 6.0），我们正在尝试移植到VS 2005.存在许多调用应用程序，因此我们尽可能地尝试保持这些向后兼容。

代码方面，结果非常简单，几个小时的开发消除了所有编译器错误和大多数警告。

然后我在链接步骤中遇到了一些“未解决的外部符号”错误，这似乎是装饰名称中的细微差别。

事实证明，一组错误与VS2005中的64位结构time_t有关 - 定义_USE_32BIT_TIME_T修复了这三种错误。

现在我遇到了两个剩余的错误：

该功能定义为

int RC_STATE::my_function(UINT stateId, UINT period, UINT index, UINT paramtype, UINT dpindex, UINT managerId, UINT calctype, UINT status, double *p_val, long *p_isc, CTime *p_time)

似乎在“旧”Visual Studio下，它对装饰名称

感到满意

?my_function@RC_STATE@@QAEHIIIIIIIIPANPAJPAVCTime@@@Z

但是现在，VS2005想要为“CTime”参数包含ATL名称空间：

?my_function@RC_STATE@@QAEHIIIIIIIIPANPAJPAVCTime@ATL@@@Z

如果我使用这个新的装饰名称更新我的.DEF文件，它会编译＆amp;链接......耶！除非我用一些曾经工作过的代码将DLL打包下来，否则它会抱怨它无法在DLL中找到过程入口点（即具有“旧”结构，没有命名空间的那个）。

有什么建议吗？是否有某种关键字，编译器指令允许我告诉编译器不要将命名空间放在装饰名称中（我知道命名空间是好的，但是CTime类型不需要命名空间到解决冲突。）

是否有任何变通方法可以使装饰名称与旧格式匹配？

非常感谢任何建议。

Answer 1

这里实际上有两个问题。首先，CTime现在位于ATL命名空间中，如您所见，但VS2005中的CTime在内部使用__time64_t，这是64位，而不是32位，并且不会通过定义_USE_32BIT_TIME_T来改变。

因此，即使您要解决命名空间问题，如果您的应用程序是使用VC6编译的，并且DLL是使用VS2005编译的（反之亦然），那么在这些模块之间传递CTime对象几乎肯定会导致由于内存布局不同导致数据损坏问题。

在我看来，解决方案是使用VS2005重新编译所有代码，并在整个过程中使用64位time_t，与VS2005中的CTime一致（即，不要使用{{1 }}）。

我希望这有帮助！

Answer 2

另一种可能性是将旧的CTime定义复制到VS2005项目中，并在您尝试保持兼容性的函数的参数列表中使用它。然后在处理之前将反向兼容的CTime参数转换为新的ATL :: CTime。旧的VC6客户端可以调用您的后向兼容方法。