On Thursday 04 of October 2012, Stephan Bergmann wrote: > On 10/04/2012 07:49 AM, Noel Grandin wrote: > > On 2012-10-03 22:03, Stephan Bergmann wrote: > >>> places. The commit seems to have caused some test failures and > >>> crashes. I reverted it for now. > >> > >> ...which only goes to show what a horrible mess C++ is in practice. > >> bool is rather special, but you easily forget to consider all the > >> consequences of that. Turns out that code like > >> aBuf.append( pElementType->pTypeName ); > >> (typelib_static_sequence_type_init, > >> cppu/source/typelib/static_types.cxx), where pElementType->pTypeName > >> is of type rtl_uString*, now chooses for overload resolution the > >> standard boolean conversion from rtl_uString* to bool (yielding true, > >> so appending "true" to aBuf) rather than the user-defined conversion > >> by constructor from rtl_uString* to rtl::OUString. > > > > Can that be fixed by adding an > > OUStringBuffer::append( rtl_uString* ) > > method, which does the necessary conversion internally? > > That would solve this specific incident, but who knows what other, > similar problems with other types would still be lurking.
I do. The only pointer type used this way with OUStringBuffer::append() is _rtl_uString. That's the good news, the bad news is that there is also const char* that should not be used this way, and adding such an overload would break the string literal overloads. I suppose this all could be solved using bool and _rtl_uString* overloads, and by making a tinderbox use a compiler plugin that checks that const char* arguments are not passed to the bool overload, but I'm not quite sure the bool overload is worth the effort. -- Lubos Lunak l.lu...@suse.cz _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
