some tweaks ?

Development
1

Hi Noel,

  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.

* 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.

* 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.

  Now we have removed the C++ ABI guarantees and map files this might be a nice cleanup, clearly simple stuff:

  Like this should stay inline (?):

     constexpr
     OUString()
     {
         pData = const_cast<rtl_uString *>(&empty.str);
     }

  But other bits like:

     explicit OUString( sal_Unicode value )
         : pData (NULL)
     {
         rtl_uString_newFromStr_WithLength( &pData, &value, 1 );
     }

  Seem to only slow down our compilation :wink: assuming that we can have the rtl_uString_newFromStr_WithLength really in-line with OUString::OUString(sal_Unicode value) that is.

  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.

* 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 ?

  Anyhow - would be good to get Stephan's view, perhaps in the TC meeting or here.

  ATB,

    Michael.

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\-&gt;length \!= asciiStrLength \)
         return false;

     return rtl\_ustr\_ascii\_compareIgnoreAsciiCase\_WithLength\( pData\-  &gt;buffer, pData\-&gt;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