On 12/05/2010 15:17, Stephan Bergmann wrote: > Of course, it turns out that my recent checking was conducted in the > wrong way (I simply grepped for traces of STLport-exported symbols in > the mangled C++ symbols exported from the URE API libs). Looking more > closely, it turns out that the URE ABI *is* tainted by STLport after all: > > Classes cppu::OPropertySetHelper (cppuhelper/propshlp.hxx) and > cppu::UnoUrlDescriptor and cppu::UnoUrl (both cppuhelper/unourl.hxx) > each have a std::auto_ptr member and non-inline constructors etc.
ah, yes... i remember replacing the void* member in OPropertySetHelper with a std::auto_ptr... but it wasn't actually my idea; somebody had told me "those are the same size on all platforms, so it's compatible" :) > (And even if one would argue that those classes are not used in OOo > extensions---which would probably hold true for the UnoUrl stuff, at > least---it would still be unsound to recompile URE without STLport: > Thanks to three layer OOo extracting out URE, multiple office > installations, old and new, can share a single URE installation, and at > least OPropertySetHelper is used within non-URE OOo code. The only > sound way out of that problem is to change URE incompatibly, which > brings us back to where we started...) but is there really a practical problem with std::auto_ptr? with the STL containers of course i'd never assume that there would be binary compatibility, but really, how many different ways are there to implement std::auto_ptr? basically it has a pointer member, and the destructor will call delete on it, right? and if the destructor of the containing class is indeed non-inline, then that's the only place where the auto_ptr destructor would be invoked (effectively making it not part of the ABI). > :( > > -Stephan regards, michael -- "C++ has the lethal combination of looking all nice and simple on the surface and having lots of traps installed under the surface, waiting for a victim." -- Yossi Kreinin --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
