This is a Feature Request:
It would be nice to consider a different dll-namingforTBB's DLLs on Windows platforms.
Here is an example for Win32 platforms:
tbb_debug.dll -> tbbd.dll
tbb_debug.dll ( MT ) -> tbbmtd.dll
tbb.dll -> tbb.dll
tbb.dll ( MT ) -> tbbmt.dll
Here is an example for Win64 platforms:
tbb_debug.dll -> tbb64d.dll
tbb_debug.dll ( MT ) -> tbb64mtd.dll
tbb.dll -> tbb64.dll
tbb.dll ( MT ) -> tbb64mt.dll
Note: MT - Multi-Threaded
Raf is not showing any disrespect. He used an idiomatic English expression that roughly means "I don't understand, so here is a clarifying question." I can see where literal translation could be trouble. Natural language is not as regular as C++.
Like Raf, I'm wondering what a non-multithreaded TBB would be. Just single-threaded versions of the algorithms and containers?
>>...Just single-threaded versions of the algorithms and containers?..
No. It refers to a C Run-Time library selected for an application or a DLL in case of development with
VS 20xx on Windows platforms.
Here are some technical details:
TBB 2.2 Update 2 commercial-aligned release
Changes (w.r.t. TBB 2.2 Update 1 commercial-aligned release):
- Building TBB with /MT is supported, to avoid dependency on particular
versions of Visual C++* runtime DLLs. TBB DLLs built with /MT
are located in vc_mt directory.
and, take a look at a screenshot:
What is a way in your proposal to avoid oversubcription in case different modules or plug-ins use different versions of TBB? Now it is solved by using the latest one TBB library across all modules in application.
I understand the naming confusion, however we will not do renaming of any kind, at least not in any near future. We want TBB to be a process-wide singleton, andto our knowledge the only reliable and secure way to approach that on Windows is to use a DLL. Naming DLLs differently (in any way - including version, bitness, dependence on VC, etc) would open a door to have multiple different TBB copies in the same process, just because different application modules (incl. 3rd party libraries, plugins etc.) might use differently named TBB DLLs. Maybe in the futureif we find a non-DLL-based way to implement a reliable and secure singleton we will considerchanging the naming schema.