some tweaks ?

Development
2 
 I was just wondering about a few tweaks we could make to cleanup and perhaps even accelerate the compilation \- and I imagine others might have some ideas\.

(I'd assume none of the below has much if any impact on build performance, but is valid cleanup anyway:)

* kill internal_only ?

 I was wondering \- do we need this:

 \#define LIBO\_INTERNAL\_ONLY

 anymore, since our APIs are now internal anyway; might be worth a clean\.

Yes, the few remaining uses of `LIBO_INTERNAL_ONLY` and its definition in `engine/solenv/gbuild/gbuild.mk` etc. could be cleaned up now.

* out-line the OUString methods as C++ methods:

 I suspect that \(at least for non PCH builds\), that rtl/oustring\.hxx and rtl/ostring\.hxx would be better using their functional call indirection as a C\+\+ function call rather than compiling and inlining this C method call and then taking the indirection there all over the place\.

A bit hard to decipher what the above paragraph wants to say---but yes, like for the next item, we probably no longer need a C API, and definitely no longer have a C ABI, so any `extern "C"` functions from that old API/ABI can likely be replaced with plain C++ functions now. (The caveat for this and for the next item is to first check that we indeed no longer have any C translation units making use of any of this.)

[...]> Then again some things like:

 bool equalsIgnoreAsciiCaseAsciiL\( const char \* asciiStr, sal\_Int32 asciiStrLength \) const
 \{
     if \( pData\->length \!= asciiStrLength \)
         return false;

     return rtl\_ustr\_ascii\_compareIgnoreAsciiCase\_WithLength\( pData\-  >buffer, pData\->length, asciiStr \) == 0;
 \}

 Are prolly performance critical to inline\.

I wouldn't be too worried about (non-)inline performance implications, in general (and then, would prefer actual measurements over guesses anyway). Many of these "do more than just call the corresponding `extern "C"` function" cases resulted from the underlying C functionality not exactly providing the sought-after semantics (and the underlying C functionality having been deemed stable and unchangeable), and not necessarily from runtime performance observations.

* cplusplus bits in osl headers:

 We still seem to have hybrid headers here:

include/osl/time.h

#if defined __cplusplus
struct TimeValue {
...

 Which \- I wonder \.\.\. is that necessary anymore ?

With the same caveat as for the previous item, yes, include files that work in a C translation unit are probably no longer needed. (So for some `foo.h` and `foo.hxx` combos, they can presumably be combined into a single `foo.hxx`. For other cases, where the `foo.h` actually *is* "proper C++", the split had traditionally been done to avoid cyclic dependencies between `.hxx` include files, so some care might be necessary when cleaning such cases up.)

Collabora Online Weekly Meeting #276