[Libreoffice] [PATCH] harmonization of BOOL vs sal_Bool as a prep for BOOL to bool converstion
michael.meeks at novell.com
Mon Oct 4 13:08:59 PDT 2010
On Mon, 2010-10-04 at 11:46 -0500, Norbert Thiebaud wrote:
> My goal is to push sal_Bool (i.e bool as unsigned char) as much as
> possible to the boundary.
Its a great goal :-)
> But I'm not sure where that ABI boundary is.
At the moment, replacing any BOOL -> bool will not cause grief; in a
blue-sky future doing a s/sal_Bool/bool/ -may- cause grief (though I'm
hopeful that even that will be ok).
> Is there a document somewhere that explain what is the ABI (IOW
> what interfaces are 'ABI public' versus interface used only internally
Well, above 'sal' - there is not much; UNO interfaces are generated and
thus hard to change to bool anyway, so - you won't have too many
problems I think.
> The way I am proceeding is to change
> typedef sal_Bool BOOL
> typedef bool BOOL
> and then compile, find problems, fix them, then change back the typedef
> re-compile - to make sure that there are still no problem
Sure - a good approach.
> and make a patch with the change so far
> Without the support of << >> fo bool, this is the first thing that
> break and I would have to re-patch them every time to move forward
> (and not forget to undo it before submitting a patch...
> Yes good point. I didn't realized then that sizeof(bool) is not
> specified by the C++ standard
> I can very easily keep the serializetion use sizeof(char).
Ah ! fine, so lets just make sure that the bool code just does a cast
to unsigned_char and calls that operator - so the intention is clear :-)
- can prolly do that with an inline in the header.
> how about setting up a git repo on github or something, so that you
> can pull from that rather than post-processsing my emails ?
Hmm - it would be a big old repo.
> > a) we don't touch any UNO-ised methods (yet) [ these are
> > generated with sal_Bool anyway ].
> Again. How do I identify for sure what constitute a UNO-ised method ?
It would have some com/sun/star/foo/StdlyCaps.hpp type header - and it
would be javaNamed();
> > c) you have checked a diff before/after of:
> > 'make vtable_check'
> > to ensure we didn't accidentally spike any virtual methods
> What does vtable_check check (*)? How to interpret the result ?
> (*) yes it check the vtables... that much I figured out :-) but bear
> with me. I'm a C guy. My C++ experience is very superficial.
Heh ;-) so - I have written a blog entry about the problem so hopefully
others can have fun too:
Hopefully this will be generally useful, not just for your
re-factoring, but for adding new features of all kinds.
michael.meeks at novell.com <><, Pseudo Engineer, itinerant idiot
More information about the LibreOffice