On 30/07/2015 18:34, Brad King wrote:
On 07/30/2015 11:23 AM, Roger Leigh wrote:
foo_EXPORT_TEMPLATE template class foo_EXPORT std::allocator<char>;
[snip]
# ifdef @EXPORT_IMPORT_CONDITION@
/* We are building this library */
# define @EXPORT_MACRO_NAME@ @DEFINE_EXPORT@
+# define @EXPORT_MACRO_NAME@_TEMPLATE
# else
/* We are using this library */
# define @EXPORT_MACRO_NAME@ @DEFINE_IMPORT@
+# define @EXPORT_MACRO_NAME@_TEMPLATE extern
# endif
[snip]
Note that I'm by no means a Windows C++ or DLL expert--I'm primarily a
C++ UNIX developer--this is just from reading the docs and experimenting.
The problem with this approach is that the non-extern explicit
template instantiation should not be done in the header file
because if more than one source file in a single library includes
the header then each of those object files will provide the
explicit instantiation. Only one source should provide the symbols.
So, one actually wants the "extern" to appear in the header
file in all cases except when included in *one* specific
source file within the library. For this there needs to
be an identifying macro associated with the source file.
Therefore it does not make sense for this macro to be defined
as part of GenerateExportHeader because that generates macros
that switch off of library-level conditions.
This is where my knowledge of Windows linking falls short.
Are the duplicated template exports here at the level of the translation
unit not elided when linking the DLL? In the dlltest git repo, I
specifically create DLLs with duplicate template exports in different
translation units to make sure it doesn't error out, and it appears to
cope. I haven't checked on whether it removed duplicates from the
linked objects though--is this even possible? I thought all current
toolchains were able to eliminate duplicate instantiations, or else
you'd have massive explosions of duplicate templates common across all
translation units. Given the backwardness of the Windows linker, it
wouldn't surprise me if it were true though...
Regards,
Roger
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
