[Libreoffice] compile-time trickery to detect misuse of SAL_N_ELEMENTS, RTL_CONSTASCII_USTRINGPARAM, etc.

[Caolán McNamara]

On Tue, 2010-11-02 at 14:26 +0000, Caolán McNamara wrote:
> On Mon, 2010-11-01 at 20:56 +0200, Jani Monoses wrote:
> > Is there a list of which compilers are supported and what versions 
> > recommeneded for building LO?
> > 
> > I was thinking of the feasibility of using gcc's __builtin_constant_p in 
> > a macro to differentiate fast and not so fast paths for createFromAscii 
> > cases to keep the code uniform but still get the optimizations, but then 
> > figured that would not work with Visual Studio.

> My first thought was that this would be ideal to at a minimum jam into
> the existing RTL_CONSTASCII_USTRINGPARAM to detect if someone used
> RTL_CONSTASCII_USTRINGPARAM with something unsuitable.

So, with a bit more poking around I discovered the template trick to
force a compile time error if the argument is not an array, and to
calculate at compile time the length of the array.

http://cgit.freedesktop.org/libreoffice/ure/commit/?h=feature/rodatastrings

Stuffed into that rodatastrings branch because there's a sad edge case
where the template cannot work with an anonymous class in current C++,
though this is fixed in the up and coming C++0x. See the comment in the
patch for the technical details.

I built with this trick earlier and found some misuses of
RTL_CONSTASCII_USTRINGPARAM, but none of them since the start of
LibreOffice, all preexisting :-)

C.