You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my experience, having finer control over exported symbols is much better than exporting all of them (either via the default behavior of GCC-and-friends or via WINDOWS_EXPORT_ALL_SYMBOLS). Among these benefits:
smaller binary size (internal template instantiation names can be hidden)
better inlining; if the compiler/LTO knows a symbol isn't exposed at all, it can be more aggressively inlined)
less chance of someone using a symbol you didn't intend to expose (more a problem in C than C++)
Instead, GenerateExportHeader should be used to generate a header with _EXPORT macros to decorate classes, functions, and variables as being available to other libraries.
The text was updated successfully, but these errors were encountered:
👍
Unfortunately we are dealing with lazy researchers who ignore this kind of issues, therefore EXPORT_ALL_SYMBOLS is the quick and dirty way to achieve the same result. 😝
In my experience, having finer control over exported symbols is much better than exporting all of them (either via the default behavior of GCC-and-friends or via
WINDOWS_EXPORT_ALL_SYMBOLS
). Among these benefits:Instead,
GenerateExportHeader
should be used to generate a header with_EXPORT
macros to decorate classes, functions, and variables as being available to other libraries.The text was updated successfully, but these errors were encountered: