我可以在VC9项目中直接使用VC6构建的C风格库吗?

发布于 2024-08-09 08:40:03 字数 178 浏览 8 评论 0原文

我们使用用 VC6 编译器构建的内部库(由其他团队开发)。该库主要包含 C 风格的 API。我们计划迁移到 Visual Studio 9 编译器。我应该要求使用 VC9 编译器构建该库吗?

一个更通用的问题,使用两个不同版本的 Visual Studio 编译器构建的 DLL 在哪些方面(可能是名称修改、优化等)有所不同?

We use an internal library(developed by some other team) built with VC6 compiler. This library mainly contains C Style APIs. We have a plan to migrate to Visual Studio 9 compiler. Should I request for the library to be built with VC9 compiler?

A more generic question, On which points ( may be name mangling, optimization etc) a DLL built with two different version of Visual Studio compiler differs?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

熟人话多 2024-08-16 08:40:03

冲突通常发生在C运行时库中。主要思想是内存应该在分配内存的模块中释放。然后就可以安全地使用用不同版本的编译器构建的库了。另一个问题是结构体的打包,但如果仅使用 Visual C++ 编译器,则没有区别。

名称修改在 Visual C++ 中因版本而异,但它仅适用于 C++ 库。如果您使用 C 风格导出(例如,如果您有 DEF 文件),则无需担心。

这个问题与您的问题并不完全重复,但可能会有所帮助。

Conflict usually occurs in C Runtime library. The main idea is that memory should be deallocated in module where it was allocated. Then it will be safe to use library that was built with different version of compiler. Another problem is packing of structs, but it has no difference if you use only Visual C++ compiler.

Name mangling is differs from version to version in Visual C++, but it applies only to C++ libraries. If you use C style exporting (for instance, if you have DEF file) then there's nothing to worry about.

This question is not a full duplicate of your, but could be helpful.

苄①跕圉湢 2024-08-16 08:40:03

AFAIK,Visual C++ 名称修饰从一个版本到另一个版本一直很稳定。

主要问题是用一个版本编译的代码必须与该版本的 CRTL 链接,并且将多个版本的代码混合到同一个 DLL 或 EXE 中将不起作用,因为这样两个目标代码都需要不同的 RTL 例程。

另一方面,如果链接包含不同库的单独 DLL,它应该可以工作。毕竟,这就是 DLL 的全部意义。

在这种情况下,我建议仅使用 extern "C" API 并(如果这是 32 位代码)显式指定调用约定(__stdcall__WINAPI_cdecl ...)

另外,当您的应用程序具有 CRTL 的多个副本时,会出现一个微妙的问题:您有多个堆!如果一个对象被分配在一个堆上并释放到另一堆上,则该堆会立即损坏并且您将崩溃。

总而言之,如果你能让它们用你的编译器重新编译,那是最简单的事情。

AFAIK, the Visual C++ name mangling has been stable from release to release.

The main problem is that code compiled with one version has to be linked with the CRTL for that version, and mixing code from multiple versions into the same DLL or EXE won't work because then both object codes expect different RTL routines.

On the other hand, if you link seperate DLLs containing the different libraries it should work. After all, that's the whole point of DLLs.

In that scenario, I would recommend using only extern "C" APIs and (if this is 32-bit code) explicitly specifying the calling convention (__stdcall__ or WINAPI or _cdecl ...)

Also, there's a subtle gotcha when your application has multiple copies of the CRTL: you have multiple heaps! and if an object is allocated on one heap and freed to a different heap, the heap is immediately corrupted and you will crash.

All in all, if you can get them to recompile with your compiler, that's the simplest thing.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文