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

On 10/03/2012 07:00 PM, Markus Mohrhard wrote:
> > > after I got tinderbox mail complaining about ambiguous overload for
> > > rtl::OUStringBuffer::append(bool) I wanted to ask if we could add a
> > > rtl::OUStringBuffer::append(bool) method or if there are reasons
> > > against it. From what I can see it could in the end even share the
> > > implementation with the sal_Bool variant just needs an own method in
> > > rtl::OUStringBuffer.
> >
> > the overloads of OUStringBuffer::append are pretty horrible already
> > (e.g. append(sal_Bool) vs. append(char) or append(sal_Unicode) which is
> > always accidentally invoked when you pass a short);  but adding
> > append(bool) won't make that any worse than it is.
>
> Seems like append(bool) is not possible without adjusting a lot of
> 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.

Stephan