Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
Hi, On 2010-06-24 at 21:30 +0200, Eike Rathke wrote: > > Anyway the change from BOOL to whatever is nothing that can be done just > > with a script. That's different for e.g. USHORT. > > Just a quick idea: define BOOL (or FASTBOOL) as some class that has > private ctors, conversion, assignment, bit and comparison operators for > all integer types, but allow conversion to integers, define private > SvStream operators, and public operators for > comparison/conversion/assignment/construction with/to/from bool. Then > compile the entire office ignoring return codes, i.e. let dmake not > break, and wade through thousands of error messages.. A decent editor > capable to digest compiler errors and position on the error is most > helpful. I'd hope that some script built around Pork or DeHydra could be used? https://wiki.mozilla.org/Pork https://developer.mozilla.org/en/Dehydra Never used any of these myself, though :-( Regards, Kendy - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
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 "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
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
Am 25.06.2010 09:20, schrieb Mathias Bauer: 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. Hi, Zhangxiaofei wants to exchange BOOL with sal_Bool on the first run. That exchange was also mentioned in a comment in the solar.h header file. I also think that this is a much easier way to get the work done and we can faster get rid of these old clashing types. Later we can do the transition from sal_Bool to bool. Regards, Carsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
"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 du...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
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
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
On 06/24/10 22:51, Terrence Enger wrote: This is about a sal_Bool rather than a bool, but I shall raise the question anyway. It just happens that I was running OO under gdb, and the following output had already caught my attention. Breakpoint 1, connectivity::OSkipDeletedSet::moveAbsolute (this=0xa85faa14, _nPos=1, _bRetrieveData=244 'ô') at /home/terry/OOo_hacking/DEV300_m83/connectivity/source/commontools/TSkipDeletedSet.cxx:170 170 sal_Bool OSkipDeletedSet::moveAbsolute(sal_Int32 _nPos,sal_Bool _bRetrieveData Is the funny value of _bRetrieveData sufficient grounds to create an issue? Technically, it should be OK; a sal_Bool value == 0 represents false, while anything != 0 represents true. However, using anything but 0/1 is error-prone and probably dubious, so looking into it would definitely be worthwhile. (There is a slim chance that this is caused by compiler optimizations and is thus harmless, or that gdb displays garbage instead of the true function arguments, but the values for this and _nPos look reasonable enough to let you assume that the value for _bRetrieveData is correct also.) -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
On Thu, 2010-06-24 at 11:32 +0200, Stephan Bergmann wrote: > On 06/24/10 11:17, Bartosz wrote: > > Maybe we should change it to (or remove this macro): > > typedef bool FASTBOOL; > > Yes, best would certainly be to remove the typedef and change > occurrences of FASTBOOL to plain bool (watching out for potential > misuses that tunnel values other than true/false through a variable of > type FASTBOOL). This is about a sal_Bool rather than a bool, but I shall raise the question anyway. It just happens that I was running OO under gdb, and the following output had already caught my attention. Breakpoint 1, connectivity::OSkipDeletedSet::moveAbsolute (this=0xa85faa14, _nPos=1, _bRetrieveData=244 'ô') at /home/terry/OOo_hacking/DEV300_m83/connectivity/source/commontools/TSkipDeletedSet.cxx:170 170 sal_Bool OSkipDeletedSet::moveAbsolute(sal_Int32 _nPos,sal_Bool _bRetrieveData Is the funny value of _bRetrieveData sufficient grounds to create an issue? Cheers, Terry. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
Hi, On Thursday, 2010-06-24 14:44:35 +0200, Mathias Bauer wrote: > In result I expect that most "BOOL" can be replaced by "bool", while > some of them will become "sal_Bool". The misused "BOOLS" that in fact > are 8 Bit integer variables(*) IMHO should become a sal_uInt8/16 just to > show that they are *not* boolean. > > Anyway the change from BOOL to whatever is nothing that can be done just > with a script. That's different for e.g. USHORT. Just a quick idea: define BOOL (or FASTBOOL) as some class that has private ctors, conversion, assignment, bit and comparison operators for all integer types, but allow conversion to integers, define private SvStream operators, and public operators for comparison/conversion/assignment/construction with/to/from bool. Then compile the entire office ignoring return codes, i.e. let dmake not break, and wade through thousands of error messages.. A decent editor capable to digest compiler errors and position on the error is most helpful. I did similar back when we replaced (Byte)String with UniString, and when I changed Calc row variables from 16bit to 32bit, and it worked well. With a global BOOL replacement it would be quite some effort though. I think I still have that class layout and definitions for general use somewhere, so if anyone is interested and feels an itch.. ;-) Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the e...@sun.com account, which I use for mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks. pgpe7B4o0sZ3T.pgp Description: PGP signature
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
On 24.06.2010 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? In result I expect that most "BOOL" can be replaced by "bool", while some of them will become "sal_Bool". The misused "BOOLS" that in fact are 8 Bit integer variables(*) IMHO should become a sal_uInt8/16 just to show that they are *not* boolean. Anyway the change from BOOL to whatever is nothing that can be done just with a script. That's different for e.g. USHORT. Regards, Mathias (*) The famous cases where a "BOOL" parameter was used as an 8 Bit integer to keep (formal) compatibility. -- 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
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
On 06/24/10 13:52, Stephan Bergmann wrote: Re memory usage: BOOL[n] and bool[n] would each be n bytes in size, or what am I missing? You're right, forget about that part. 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. If you write new code, you see what you're doing. In existing code, BOOL and sal_Bool are often used interchangeably. sal_Bool only belonging to UNO may be a good idea, but not reality. And I don't see an easy way to adapt existing code to that rule. If we change the typedef and then go through the list of compiler errors, we'll only end up with something like "sal_Bool bSalFoo(bFoo); process(bSalFoo); bFoo=bSalFoo;" and probably still break something that's found only years later. Re the occasional "special" value: I guess one day we should bite the bullet and clean those up for good. That might be a good thing anyway. But then it should be done separately, so the result can be compiled and tested immediately. Niklas - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
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? 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. Re the occasional "special" value: I guess one day we should bite the bullet and clean those up for good. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
On 06/24/10 13:07, Bartosz 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? I agree with you Niklas. It will be much better/safer to change FASTBOOL to sal_Bool. I was talking about BOOL, not FASTBOOL. FASTBOOL usage is much more limited. Replacing FASTBOOL with bool seems possible and more in line with its original intention. I agree with Stephan that it's best to remove the FASTBOOL type altogether and change the places where it's used (much fewer than for BOOL). Niklas - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
> > "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? I agree with you Niklas. It will be much better/safer to change FASTBOOL to sal_Bool. Does sal_Bool(unsigned char) is slower than FASTBOOL (int)? It could make OpenOffice.org code slower if it will call functions with bool parameters a lot. I don't want to loose the performance, see: http://cboard.cprogramming.com/cplusplus-programming/119320-bool-vs-int-faster.html Regards Bartosz - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
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? Niklas - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
Hi, On 24.06.2010 11:17, Bartosz wrote: Hi. What do you think about replace macro "FASTBOOL" with "bool"? http://svn.services.openoffice.org/opengrok/xref/DEV300_m83/tools/inc/tools/solar.h#FASTBOOL For now the FASTBOOL is defined as: typedef int FASTBOOL; Maybe we should change it to (or remove this macro): typedef bool FASTBOOL; It was done, because "int" was faster than "bool". More info: http://cboard.cprogramming.com/cplusplus-programming/119320-bool-vs-int-faster.html Modern compilers are very smart, and I think we should leave optimization to them. What do you think about this idea? 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. 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
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
+1 for removing this ancient thing. Not for memory reasons (I doubt it would really make a difference), but for code cleanup reasons. I don't know how risky this is when it comes to the binfilter module. If the old binary filters simply stream FASTBOOL variables, the document format would become incompatible. But IIRC we seldom used stream operators in our filters, but used SvStream::Read/Write(...), which would be fine then. So you should first check if this is the case... Malte. Stephan Bergmann wrote, On 06/24/10 11:32: > On 06/24/10 11:17, Bartosz wrote: >> Maybe we should change it to (or remove this macro): >> typedef bool FASTBOOL; > > Yes, best would certainly be to remove the typedef and change > occurrences of FASTBOOL to plain bool (watching out for potential > misuses that tunnel values other than true/false through a variable of > type FASTBOOL). > > -Stephan > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.org > For additional commands, e-mail: dev-h...@openoffice.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
On 06/24/10 11:17, Bartosz wrote: Maybe we should change it to (or remove this macro): typedef bool FASTBOOL; Yes, best would certainly be to remove the typedef and change occurrences of FASTBOOL to plain bool (watching out for potential misuses that tunnel values other than true/false through a variable of type FASTBOOL). -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] "FASTBOOL macro" vs "bool" - decrease memory usage
Hi. What do you think about replace macro "FASTBOOL" with "bool"? http://svn.services.openoffice.org/opengrok/xref/DEV300_m83/tools/inc/tools/solar.h#FASTBOOL For now the FASTBOOL is defined as: typedef int FASTBOOL; Maybe we should change it to (or remove this macro): typedef bool FASTBOOL; It was done, because "int" was faster than "bool". More info: http://cboard.cprogramming.com/cplusplus-programming/119320-bool-vs-int-faster.html Modern compilers are very smart, and I think we should leave optimization to them. What do you think about this idea? Best Regards Bartosz - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
