On 06/24/2010 12:42 PM, Niklas Nebel wrote:
On 06/24/10 12:29, Mathias Bauer wrote:
The idea is so good that someone is already working on it. :-)
There is ongoing work to replace a lot of ancient types like BOOL,
USHORT etc. by sal_... types, with the exception that BOOL/FASTBOOl
will be replaced by bool.
"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. While that is annoying enough, it becomes a pain if you use
precompiled headers. So it happens at times that a Windows build works
without PCH but breaks with them. I had that several times in the past.
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. We
should ask the developers doing the work (some guys from RedOffice) what
their own choice is. I don't know if they are reading this list, they
surely read d...@framework, so I will ask there.
Regards,
Mathias
--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamfor...@gmx.de".
I use it for the OOo lists and only rarely read other mails sent to it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
