Which internal mechanisms should be still DLL-exported in vNext? #3871
-
|
There're several issues saying that some internal mechanisms shouldn't be exported in vNext. Conversely, it seems that only a few internal mechanism should be exported. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
We should DLL-export (with flat C functions only) mechanisms that are still used by the headers, while we shouldn't DLL-export things that aren't used by the headers. (They should either remain purely internal to the STL's DLL and static LIB - we currently have a number of functions that are used only for cross-TU "communication" within the STL's DLL and static LIB and are uselessly DLL-exported despite not being mentioned by the headers at all - or they should be identified as completely dead code and outright eliminated.) |
Beta Was this translation helpful? Give feedback.
We should DLL-export (with flat C functions only) mechanisms that are still used by the headers, while we shouldn't DLL-export things that aren't used by the headers. (They should either remain purely internal to the STL's DLL and static LIB - we currently have a number of functions that are used only for cross-TU "communication" within the STL's DLL and static LIB and are uselessly DLL-exported despite not being mentioned by the headers at all - or they should be identified as completely dead code and outright eliminated.)