blocks|key|2848722|text|您可以通过对I/O和任何其他可能依赖于运行时的东西使用WinAPI调用来实现这一点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2848723|最痛苦的部分是，您可能必须覆盖全局new和delete才能独占使用WinAPI函数，因为它们很可能在内部使用malloc/free。还有许多其他痛苦的方面，我的意见是，这不值得麻烦。Here就是一篇介绍这个主题的文章。|offset|length|style|CODE|2848724|entityMap|0|LINK|mutability|MUTABLE|url|http://www.catch22.net/tuts/minexe^0|0|H|3|L|6|2J|4|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@$D|R|E|S|F|G]|$D|T|E|U|F|G]]|9|@$D|V|E|W|1|X]]|A|$]]|$1|H|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

You can achieve this by using WinAPI calls for I/O and anything else that possibly relies on the runtime. 

The most painful part is that you may have to override the global <code>new</code> and <code>delete</code> to use WinAPI functions exclusively because they are likely to use malloc/free internally. There are many other painful aspects to this, and my opinions is that it isn't worth the trouble. <a href="http://www.catch22.net/tuts/minexe" rel="nofollow">Here</a> is an article that covers this topic.

blocks|key|2564525|text|您的dll链接到编译它时所用的C运行时。您的应用程序将始终使用此运行时。任何链接到你的dll的人都会使用他们的c运行时。所以这不会有任何问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2564526|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Your dll is linked against the c-runtime it was compiled with. Your application will always use this runtime. Anyone who links to your dll uses their c-runtime. So there won't be any problem with this.

blocks|key|2848784|text|链接你的动态链接库和静态运行时库应该是可行的，除了你必须非常小心内存管理(例如，任何调用你的动态链接库的人都不能释放()或者释放任何由你的动态链接库分配的东西)，并且你不能交换标准的C数据结构(例如delete[]+*)。(我是否遗漏了什么？)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2848785|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Linking your DLL against the static runtime libs should work, except that you must be very careful about memory management (e.g. whoever calls your DLL can't free() or delete[] anything allocated by your DLL) and you cannot exchange standard C data structures (e.g. FILE*). (Am I missing anything?)

blocks|key|2564600|text|没有真正的方法来确保您的DLL可以与多个运行时一起工作--任何在它们之间进行更改的类型都可能导致不兼容。例如，对象的大小可以改变，或者成员在其中的位置可以改变。在C%2B%2B中，这种事情的空间非常小。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2564601|您能做的最好的事情就是静态地链接到运行时，并确保导出的API被严格限制在您的控制之下--不将std::string传递给函数，不将stdlib类型作为成员，并且不在一个DLL中使用new，在另一个DLL中使用delete。不要为同一对象混合内联和导出函数(包括构造函数/析构函数)，因为成员顺序和填充可能会在编译器之间发生变化。pimpl习惯用法在这方面可能会有所帮助。|offset|length|style|CODE|2564602|entityMap^0|0|1A|B|2I|3|2W|6|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]|$D|N|E|O|F|G]|$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|I|$]]

There's no real way to ensure your DLL works with multiple runtimes -- any of the types that change between them can lead to incompatibilities. For instance, the size of an object can change, or the location of members in them. There is very little room in C++ for this kind of thing.

The best thing you can do is statically link to the runtime and ensure the exported API is limited to types strictly under your control -- no passing <code>std::string</code> to a function, no stdlib types as members, and don't <code>new</code> in one DLL and <code>delete</code> in another. Don't mix inline and exported functions (including constructors/destructors) for the same object, because member order and padding might change between compilers. The pimpl idiom might help here.

blocks|key|947265|text|如果你想以一种运行时中立的方式公开你的对象，那么除了COM，我看不到任何其他的解决方案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|947266|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you want to expose your objects in a runtime neutral way then I can't see any solution other than COM.

blocks|key|2849015|text|如果您跨DLL边界公开任何C%2B%2B对象，那么这是完全不可能的。您可以做的(我们使用第三方DLL来完成此操作)是以多种配置(32位/64位、调试/发布、静态/动态运行时、静态/动态库)构建您的库，以满足尽可能多的人的需求。一开始设置可能有点繁琐，但是一旦你完成了所有配置的设置，就需要构建所有的配置了。当然，您还需要考虑针对哪个运行时(vc8、vc9、vc10等)进行构建，因此，如果您想涵盖所有基础，您可能会有相当多的配置。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2849016|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you expose any C++ objects across DLL boundaries then this is simply not possible. What you can do (and we use a 3rd-party DLL that does this) is build your library in multiple configurations (32-bit/64-bit, debug/release, static/dynamic runtime, static/dynamic library) to satisfy as many people as possible. This may be a bit tedious to setup at first, but once you have all the configurations setup it's just a matter of building them all. Of course you also need to consider which runtime you are building against (vc8, vc9, vc10, etc), so if you want to cover all the bases you could have quite a lot of configurations.

blocks|key|2849043|text|嗯，C运行时和C%2B%2B运行时之间有很大的不同。如果你在哪里使用msvcrt.dll，它在最近几年成为一个真正的系统动态链接库，你可以依赖于它在XP上的存在(尽管对于Windows2000，你需要一些msvcrt.dll版本6的可再发行的)。您可以通过使用最新的WDK+(Windows+Driver+Kits)中的编译器编译您的代码来使用msvcrt.dll。即使这是用户模式的代码，这也是一种可行的好方法来编译它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2849044|然而，IOStreams需要C%2B%2B运行时。这让事情变得复杂了很多。|2849045|2849046|编辑:将dll链接到静态运行时库也不起作用，因为这样静态运行时(来自dll)和动态运行时(来自客户端应用程序)将混合在一起，这是不好的。|blockquote|2849047|2849048|2849049|好吧，如果你以这种方式混合代码，那么你的设计就有问题了。当使用其他代码的发布版本运行DLL的调试版本时，也会遇到类似的问题，反之亦然。|2849050|我只能建议您直接使用COM，或者-如果太大了-尝试效仿COM的一些想法。最重要的一点是你有一个工厂函数，并且在这两段代码(即DLL和它的调用者)之间有一个声明的(类)接口(永远不会改变)。工厂函数将返回类的实例，并且类将管理其生命周期本身(这意味着用于分配和释放的所有代码将驻留在同一实体中，即您的DLL)。生命周期管理随后将通过addref和release成员函数公开。IUnknown可以作为您的这个接口的基础，而不依赖于实际COM的其他部分。|offset|length|style|CODE|2849051|2849052|编辑:我主要问的是，我如何告诉运行时加载器将我的dll链接到应用程序所链接的任何CRT？也许是和载货单有关的东西？更广泛地说，我的问题是如何构建一个行为良好的dll，供客户构建他们自己的应用程序使用？|2849053|2849054|2849055|一点也不容易。即使您安装了VS的所有版本，您也必须编写脚本来选择正确的版本，以摆脱这种困境。|2849056|entityMap^0|0|0|0|0|0|0|0|4L|6|4S|7|56|8|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|13|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|16|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|17|8|@$N|18|O|19|P|Q]|$N|1A|O|1B|P|Q]|$N|1C|O|1D|P|Q]]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|S|3|T|5|G|7|1F|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1I|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]]|Z|$]]

Well, there is a huge difference between the C-runtime and the C++-runtime. If you where to use msvcrt.dll, which in recent years became "knighted" as a true system DLL, you could rely on its existence on XP onwards (though for Windows 2000 you would need some redistributable for the version 6 of msvcrt.dll). You can make use of msvcrt.dll by compiling your code with the compiler from the latest WDKs (Windows Driver Kits). Even though this is user-mode code, this is a viable and good method to compiler it.

IOStreams, however, require the C++-runtime. And that complicates things a lot.

<blockquote>
 EDIT: linking the dll against the
 static runtime libs won't work either,
 because then the static runtime (from
 the dll) and the dynamic runtime (from
 the client's application) will be
 mixed, which is bad.
</blockquote>

Well, if you mix code in such a way, you have something wrong in your design. You would have similar problems when running a debug build of your DLL with a release build of the other code or vice versa.

I can only recommend that you either make direct use of COM, or - if that's too big - try to emulate some ideas of COM. The most important one would be that you have a factory function and that there is an (class) interface declared (and gets never changed) between those two pieces of code (i.e. the DLL and its caller). The factory function would return an instance of the class and the class would manage its lifetime itself (which implies that all code for allocation and deallocation would reside in the same entity, i.e. your DLL). The lifetime management would then be exposed via <code>addref</code> and <code>release</code> member functions. <code>IUnknown</code> could be the basis for this interface of yours without relying on other parts of the actual COM.

<blockquote>
 EDIT: What I'm mainly asking is how do
 I tell the runtime loader to link my
 dll against whatever CRT the
 application is linked with? Something
 with the manifest, perhaps? More
 generally, my question is how to build
 a nicely-behaving dll, that's to be
 used by clients building they're own
 applications?
</blockquote>

Not easy at all. Even if you had all the versions of VS installed, you'd have to script your way out of this dilemma to pick the right version.

blocks|key|2849074|text|如果使用C%2B%2B，似乎不可能跨越运行时边界，除非您将自己限制在可以公开的内容上。如前所述，std:：对象不起作用(例如std：：string)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2849075|下面是一个将导致崩溃的小示例：|2849076|类基础|2849077|{|code-block|syntax|javascript|2849078|public:|2849079|++virtual+~Base()|2849080|++{|2849081|++}|2849082|};++|2849083|ClassInDll类:公共基类|2849084|{公共：__declspec(+dllexport+)+ClassInDll(+int+arg+)；|2849085|\_\_declspec(+dllexport+)+~ClassInDll();++|2849086|private:+int+_arg；|2849087|}；|2849088|如果此类编译为VS2008发布模式DLL，并且在VS2008调试模式下构建.exe，请执行以下操作：|2849089|ClassInDll*+c=新建ClassInDll(+1+)；删除c；|2849090|"delete+c“语句会导致崩溃。这与ClassInDll有一个虚拟析构函数的事实有关。|2849091|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1D|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1E|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|1F|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|H|7|1G|8|@]|9|@]|A|$I|J]]|$1|M|3|N|5|H|7|1H|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|H|7|1I|8|@]|9|@]|A|$I|J]]|$1|Q|3|R|5|H|7|1J|8|@]|9|@]|A|$I|J]]|$1|S|3|T|5|H|7|1K|8|@]|9|@]|A|$I|J]]|$1|U|3|V|5|6|7|1L|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1M|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|H|7|1N|8|@]|9|@]|A|$I|J]]|$1|10|3|11|5|6|7|1O|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1P|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|1R|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|1S|8|@]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]]|1B|$]]

If you use C++, it seems to be impossible to cross runtime boundaries unless you limit yourself on what can be exposed. As mentioned earlier, std:: objects do not work (std::string for instance).

Here is a small example that will cause a crash:

class Base 
 { 
 public: 
 virtual ~Base() 
 { 
 } 
 }; 

class ClassInDll : public Base 
{
public:
 __declspec( dllexport ) ClassInDll( int arg ); 
 __declspec( dllexport ) ~ClassInDll(); 

private:
 int _arg; 
}; 

If this class is compiled into a VS2008 release mode DLL and one builds a .exe in VS2008 debug mode doing the following:

ClassInDll* c = new ClassInDll( 1 );
delete c;

the "delete c" statement causes a crash.
It has to do with the fact that ClassInDll has a virtual destructor.

My product is a C++ library, which, on Windows, is distributed as a dll. It makes very little use of the c-runtime (basic iostream and that's it), so I'm sure that all recent versions of the CRT will be fine.

Since my client is supposed to build his application using my dll, I don't want to impose upon him any specific runtime version. I'd like my dll to bind to whatever runtime library version my client's app is using (and I can assume that he'll use dynamic linking for his CRT). After all, isn't that what dynamic linking is all about? Is that possible?

EDIT: linking the dll against the static runtime libs won't work either, because then the static runtime (from the dll) and the dynamic runtime (from the client's application) will be mixed, which is bad.

EDIT: What I'm mainly asking is how do I tell the runtime loader to link my dll against whatever CRT the application is linked with? Something with the manifest, perhaps?
More generally, my question is how to build a nicely-behaving dll, that's to be used by clients building they're own applications?

EDIT: Thanks to the advice in the answers, I've transferred all references to std classes into inlined functions in my headers, and linked my dll with the static runtime libraries. It now seems to work even in applications linked with different CRT versions.

How do I build a runtime version agnostic DLL in C++?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我的产品是一个C++库，在Windows上，它是作为dll分发的。它很少使用c运行时(基本的iostream就是这样)，所以我确信所有最新版本的CRT都会很好用。因为我的客户应该使用我的dll构建他的应用程序，所以我不想强加给他任何特定的运行时版本。我希望我的dll绑定到我客户的应用程序正在使用的任何运行时库版本(我可...

问如何在C++中构建与运行时版本无关的动态链接库？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何在C++中构建与运行时版本无关的动态链接库？EN