On 24/06/2010 13:52, Stephan Bergmann wrote: > On 06/24/10 12:42, 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? > > Re memory usage: BOOL[n] and bool[n] would each be n bytes in size, or > what am I missing?
isn't bool ususally (or at least sometimes) 4 bytes in size? but actually instead of BOOL[n] some kind of bit vector could be used, which would take even less space, right? > Re mixed use with sal_Bool: haven't encountered this problem often over > the last years (and I liberally use bool instead of sal_Bool/BOOL since > ages) -- also, it might be better to try to adapt the mismatching uses > of sal_Bool to bool, too, leaving usage of sal_Bool to the only place it > belongs, C++ UNO. actually, i've just recently cleaned up a part of the UNO API implementation in the writer; a few of the method implementations used BOOL in the signature instead of sal_Bool (usually the header used one and the implementation the other...) this happens to work because C++ doesn't take type safety seriously, and they're both unsigned char. that's something to watch out for: here BOOL must be replaced with sal_Bool. > Re the occasional "special" value: I guess one day we should bite the > bullet and clean those up for good. seconded. > -Stephan -- Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
