On 12/12/08 13:23, stephan.bergm...@sun.com wrote:
Type: required Title: Problems with deriving SAL_DLLPUBLIC classes from all-inline classes on MSC Posted by: stephan.bergm...@sun.com 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.
--------------------------------------------------------------------- To unsubscribe, e-mail: interface-announce-unsubscr...@openoffice.org For additional commands, e-mail: interface-announce-h...@openoffice.org