"BOOL -> bool" will cause problems. Memory usage for "new BOOL[n]",
mixed use with sal_Bool (pointers, references), the occasional
"special"
value (SfxChildWinInfo::bVisible). Shouldn't we go the safe way and
change BOOL to sal_Bool instead?
Thinking again about suggestion I'm starting to see its merits. It's
not because it's more safe (we should be able to do both changes in
the right way), but it's surely faster.
The primary motivation of us (the framework team) to start that work
was that we wanted to get rid of a possible build breaker that has
hit us every few months in the past.
Types like BOOL, USHORT etc. are not only defined in tools/inc/tools/
solar.h, but also in a Windows header. Moreover, the Windows API
header defines them differently in many cases. So if you use the
tools types, you must avoid to include the "offending" Windows
headers.
This problem has been solved for many years now by using wrappers for
external headers such as tools/prewin.h+tools/postwin.h tools/prex.h
+tools/postx.h or tools/premac.h+tools/postmac.h.
A change from BOOL to sal_Bool indeed would be much faster than an
attempt to use bool as much as possible, so it would be tempting to
go that road and postpone a further replacement of sal_Bool by bool.
The wrappers mentioned above are a bit hacky and I'd be happy to get
rid of them. With the conflicting definitions for the fundamental
types gone this would be a step in that direction. So +1 from me
getting rid of "our BOOL".
---
Herbert Duerr
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
