Exporting templates on Windows (Re: [Libreoffice-commits] .: 7 commits - clucene/patches clucene/source configure.in cppuhelper/inc hwpfilter/source sal/inc solenv/gbuild vbahelper/inc)

 Windows/MSVC experts

On Monday 12 of March 2012, Stephan Bergmann wrote:
> On 03/10/2012 04:39 PM, Lubos Lunak wrote:
> > commit 34f8495dd948e2ad9d64c2c19110e69840cefd1a
> > Author: Luboš Luňák<l.lunak@suse.cz>
> > Date:   Sat Mar 10 15:37:02 2012 +0100
> >
> >      exported templates need to be marked as such
> >
> >      Otherwise their instances created in other modules may end up
> >      as non-exported even when used by something exported.
> >
> > diff --git a/cppuhelper/inc/cppuhelper/compbase.hxx
> > b/cppuhelper/inc/cppuhelper/compbase.hxx index 60e99ee..e590412 100644
> > --- a/cppuhelper/inc/cppuhelper/compbase.hxx
> > +++ b/cppuhelper/inc/cppuhelper/compbase.hxx
> > @@ -41,7 +41,7 @@
> >   namespace cppu \
> >   { \
> >   template<  __CLASS_IFC##N>  \
> > -class SAL_NO_VTABLE WeakComponentImplHelper##N \
> > +class SAL_NO_VTABLE CPPUHELPER_DLLPUBLIC WeakComponentImplHelper##N \
> >
> >       : public ::cppu::WeakComponentImplHelperBase \
> >
> >       , public ImplHelperBase##N<  __IFC##N>  \
> >   { \
>
> Does this workaround for <http://llvm.org/bugs/show_bug.cgi?id=10113>
> (where I'm still not convinced it is a user error vs. a compiler error)

 I am rather convinced that the original issue 
(without -fvisibility-inlines-hidden) is a user error, so I consider this to 
be a proper fix rather than a workaround.

 Imagine for example that the template has a static data member - that one 
would need to be merged to be just in one place, and that just wouldn't work 
if the template was public API but hidden. So in general I think templates 
need to be exported (also look e.g. at STL headers, which export the entire 
std namespace, although I can see that Qt templates don't).

> work well with MSVC?  I wonder because there all consumers of the
> template (outside of cppuhelper) will see it as __declspec(dllimport),
> and (as long as there is no instantiation in cppuhelper) there is no
> place that would emit it as __declspec(dllexport).

 I don't know about MSVC. Meaning that I haven't tried and I don't know how 
export/import works on Windows anyway.

 But it doesn't make much sense to me. It is not actually the template itself 
that is or is not exported, because that's just a compile-time concept, but 
it's instances of it as binary concept that are exported. And how does 
something know whether some other library does or does not contain Foo< int > 
without actually looking?

 Assuming that this commit really breaks it on MSVC and the proper change 
there is to remove the DLLPUBLIC from the template and hope the compiler and 
linker sort it out somehow, then I guess we'll need to add 
SAL_TEMPLATE_DLLPUBLIC which does nothing with MSVC and the right thing with 
gcc/clang.

 MSDN article on the dllimport/dllexport flags feels like it doesn't actually 
say anything, but reading http://support.microsoft.com/kb/132044/en-us makes 
me think the flags are just optimizations, so nothing will break. But 
according to it SAL_TEMPLATE_DLLPUBLIC would be the right thing.

 Windows/MSVC experts, any ideas/opinions?

-- 
 Lubos Lunak
 l.lunak@suse.cz