Why only dynamic C/C++ runtimes?

[paultomographix_com]

Hello,

I apologize if this is a commonly asked question, but I was not able to find an answer by searching the forums. I am porting an established commercial project to Visual Studio 2008 with the commercial versions of the Intel C++ compiler 11.0 and TBB 2.1, and have run into a snag with TBB's requirement of using only the dynamic versions of the C/C++ runtimes. The project currently relies on a number of other libraries that all use the static runtimes.

I understand the need to put TBB in a DLL to ensure there is only one copy of it running on a system for scheduling purposes etc., but why are there not two versions of the DLLs that are linked with the static and dynamic versions of the C/C++ runtimes, respectively?

Also,I understand that there is a theoretical risk in mixing, say, the dynamic C/C++ runtimes linkedin TBB with the static ones used by the rest of my project, and I get the TBB warning message in the build output when I try to do this . . . but it does work. What are the practical risks of proceeding with a mixture of this kind? Does anyone out there have any experience with bad outcomes?

Thanks,
Paul

[robert-reed]

Quoting - paultomographix.com

I understand the need to put TBB in a DLL to ensure there is only one copy of it running on a system for scheduling purposes etc., but why are there not two versions of the DLLs that are linked with the static and dynamic versions of the C/C++ runtimes, respectively?

Also,I understand that there is a theoretical risk in mixing, say, the dynamic C/C++ runtimes linkedin TBB with the static ones used by the rest of my project, and I get the TBB warning message in the build output when I try to do this . . . but it does work. What are the practical risks of proceeding with a mixture of this kind? Does anyone out there have any experience with bad outcomes?

Well the risk of mixing any two versions of the same runtime in the same program is that some functions will call one version of functions in the library while other program functions call the other library. If there are any static data retained by the libraries, they will not be shared. If there are differences in the behavior of the functions, you might get some very weird, hard to trace down bugs. Just because you get a successful result in your current tests doesn't mean you'll always be so lucky. Multiple versioning can be an issue whether you are dealing with static or dynamic libraries. Given that potential for ambiguity and error, it's very unlikely we would release a TBB DLL linked with a static C runtime even as a special.

[paultomographix_com]

Thanks for your reply Robert. Dynamic runtimes it is.

[Dmitry_Vyukov]

Statically linked TBB is indeed works (it's not very difficult to compile it in that mode - just define few macros). Hovewer I am not calling anybody to use such mode, because it's indeed undocumented. I'm only hoping that TBB team will not break this feature in the future :)