Re: required/sb102 : Problems with deriving SAL_DLLPUBLIC classes from all-inline classes on MSC

On 12/12/08 13:23, [email protected] wrote:
> 
>           Type: required
>          Title: Problems with deriving SAL_DLLPUBLIC classes from all-inline classes on MSC
>      Posted by: [email protected]
>       Affected: connectivity
>          TaskId: i95065
> <http://www.openoffice.org/issues/show_bug.cgi?id=95065>
> Effective from: sb102
>            CWS:
> <http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300/sb102>
>     CWS status: new
> 
> 
> *Summary*
> --------
> connectivity::ORefVector
> chart2 apphelper::LifeTimeGuard
> 
> *Description*
> -------------
> On MSC, when a class is marked as SAL_DLLPUBLIC_EX-/IMPORT, all its
> base classes that are not yet otherwise marked as SAL_DLLPUBLIC_IMPORT
> are apparently treated as SAL_DLLPUBLIC_EX-/IMPORT, too.

More specifically:  "Because this is common pattern with templates, the 
compiler changed the semantics of dllexport when it is applied to a 
class that has one or more base-classes and when one or more of the base 
classes is a specialization of a class template. In this case, the 
compiler implicitly applies dllexport to the specializations of class 
templates." [<http://msdn.microsoft.com/en-us/library/twa2aw10.aspx>; 
thanks to Björn for the pointer]

-Stephan

> This causes link errors when such a base class is also used in a
> context where it is not considered SAL_DLLPUBLIC_EX-/IMPORT, and
> cannot be changed to be SAL_DLLPUBLIC_IMPORT because it is all
> inline.
> 
> This happened with connectivity::ORefVector, which was originally
> derived from std::vector, and chart2's apphelper::LifeTimeGuard, which
> was originally derived from osl::ResettableMutex.  Both had to be
> changed, where changing the former (introduction of Vector member
> typedef and get() member functions) caused substantial (trivial)
> change in depending source files in connectivity and dbaccess.