On Mon, 2011-02-28 at 22:50 +0100, Sébastien Le Ray wrote: > Le Mon, 28 Feb 2011 21:45:36 +0000, > Caolán McNamara <caol...@redhat.com> a écrit : > > > On Sun, 2011-02-27 at 04:27 -0500, Kevin Hunter wrote: > > Three possibilities I guess, > > > > 1) remove the "explicit", but I'm sure its there due to some other > > horribly implicit conversion horror > > 2) add a operator+(sal_Char), either one that "just works", or one > > that raises an error at compile time. > > 3) remove the const sal_Char* conversion operator (I'm tempted towards > > this one) > > If someone takes this, he/She should add a operator[](int) to allow > byChar access (or a getChar method)...
I did a demo test on this, and I think removing the cast operator is the way to go and adding a operator[] which silently replaces it in the vast majority of cases. I found at least two places where people already fell into the same trap as in your example, e.g. the one now fixed by 44447f718d95d002815eb6f176692132f077770f in libs-core and some others. Also a bunch of horrors where there's a "addRelation" method which takes two strings and a boolean, but is passed three strings in loads of places, where the final string is auto-converted to a sal_Unicode*, and its NULL/non-NULL value taken as the final bool. Sigh. (unfixed btw, see call of addRelation in oox/source/export/drawingml.cxx as an example) Along with a rash of places where we fairly pointlessly construct a OString from a string literal, and pass the OString to something which actually takes a const char* which works because of the conversion operator. C. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
