Understand the behavior and limitations of the STL import library
mainThe STL's import library (.lib) is unique because it does more than just define symbols imported from a DLL; it also defines certain functions and variables directly within the library. This allows for extending the STL (e.g., adding <filesystem> support) without changing the DLL export surface and improves throughput by compiling constant data (like <charconv> lookup tables) separately.
Critical Limitations
When working with or building against this library, be aware of these constraints:
- No Shared Global State: Because the import library embeds part of the implementation into every user binary that links to it, variables in the import library cannot represent shared global state. If your application requires shared global state across DLL boundaries, a satellite DLL must be used instead.
- Bypassing
/MDand/MDd: This technique embeds part of the STL implementation into the user's binary, which partially defeats the purpose of using the/MD(Release) or/MDd(Debug) compiler options. - Iterator Debug Level Constraints: Because there are only two flavors of the import library (Debug and Release), the library cannot use anything that depends on
_ITERATOR_DEBUG_LEVEL. - Implementation Restrictions: To avoid the issues above, the import library is restricted to core headers only. For example,
basic_stringmust not be used within the import library.