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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
