On 06/25/2010 10:48 AM, Herbert Duerr wrote:
"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.
No, that doesn't work when PCH come into play, as experience shows. And
it's an awful hack. Those who "invented" it (instead of *fixing* the
problem when it was much easier than today as we had much less code!)
should be punished by urging them to watch soccer games from France and
Italy for at least three days without pausing. :-)
Ciao,
Mathias
--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[email protected]".
I use it for the OOo lists and only rarely read other mails sent to it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
