2

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

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

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

事实证明，一组错误与 time_t 是 VS2005 中的 64 位结构有关——定义_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 文件，它会编译和链接......耶！除了当我用一些曾经可以工作的代码将那个 DLL 放下时，它抱怨它无法在 DLL 中找到过程入口点（即具有“旧”结构的入口点，没有命名空间）。

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

是否有任何解决方法可以使修饰名称与旧格式匹配？

非常感谢任何建议。

4

2 回答 2

3

这里实际上有两个问题。首先，正如您所发现的，CTime现在在ATL名称空间中，而且CTime在 VS2005__time64_t内部使用，它是 64 位，而不是 32 位，并且不会通过定义_USE_32BIT_TIME_T.

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

time_t在我看来，解决方案是使用 VS2005 重新编译所有代码，并始终使用 64 位，与CTimeVS2005 一致（即不要使用_USE_32BIT_TIME_T.

我希望这有帮助！

于 2009-01-24T00:34:21.670 回答
1

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

于 2009-01-25T18:10:26.393 回答