Re: using bool in rtl::OUStringBuffer::append

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.lunak@suse.cz