Re: shouldn't XFoo implementations use sal_Bool, and not bool?

On 06/01/2015 03:50 PM, Lionel Elie Mamane wrote:
> On Mon, Jun 01, 2015 at 09:19:40AM +0200, Stephan Bergmann wrote:
> > The functions are apparently copied from XResultSet (incl. presumably
> > unnecessary virtual and SAL_CALL, even), but technically they are unrelated.
> > That means there is no technical reason to make them use the inferior
> > sal_Bool instead of bool (and loplugin:salbool should warn about such
> > unnecessary uses of sal_Bool).
>
> Well, OTOH your tinderbox complains that a bool is compared to a
> sal_Bool, and for functions that are copied from XResultSet putting

== and != comparison between real bool and pseudo-Booleans like sal_Bool 
(which, after all, would cover all char values) is both rare enough and 
dangerous enough to IMO warrant such a warning and the need to 
explicitly acknowledge and silence it with a cast.

> explicit casts is unnatural. In essence, the "cache" objects presents
> the same API as the object it caches, but it just happens that all
> users of the cache know they are dealing with a cache, so they don't
> use the abstract base (interface) class (css::sdbc::XResultSet), but
> use the "Cache" object class directly.
>
> I think I prefer to add the inheritance from the
> "css::sdbc::XResultSet" interface class, so that the things I just
> explained are visible to the tools.

IMO that wouldn't make it better.  There is a known impedance mismatch 
between UNO C++ code and natural C++ code, and at the seams that 
sometimes manifests as little warts.  Shrug.