Re: [Libreoffice] uno discoverability

On 11/17/2011 06:55 PM, Michael Meeks wrote:
> On Wed, 2011-11-16 at 14:16 +0100, Stephan Bergmann wrote:
> > >         throw FooException("Failure loading file '%S' code %d",
> ...
> > This (as well as cooking something up using OSL_FORMAT) would have the
> > disadvantage that it potentially converts data from UTF-16 to char
> > ("%S") and then from char to UTF-16 (as UNO Exception's Message is of
> > type rtl::OUString).
>
>         True - but by the time we throw an exception, efficiency already goes
> to hell in a hand-cart (as it were) ;-) we start straining mind and limb
> to find unwind info records, infer types, understand what is on the
> stack and how to clean it up etc. An extra allocation or two isn't going
> to hurt.

Its not any time/space overhead that makes me feel uneasy here, but the 
lack of elegance and of consistency.  We could come up with a mechanism 
now for composing exception messages using the new sal/log.h SAL_STREAM, 
like

  throw RuntimeException(rtl::OUString(SAL_STREAM("cannot open " << 
url).c_str()));

or even simplify that further with an additional macro like

  throw RuntimeException(SAL_STRING("cannot open " << url));

Then again, the standard LO idiom to create a literal rtl::OUString is 
rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("...")), and the standard LO 
idiom to compose a string from to substrings is s1 + s2.  This is not 
only so for the special case of composing messages of UNO exceptions, it 
is so across all the code.  It is somewhat long-winded and ugly, but 
within today's constraints we won't be able to come up with something 
that is substantially better with regard to space/time complexity.

If we would optimize the "user experience" of composing exception 
messages (where the resulting space/time overhead would be harmless), we 
would pessimize the standard idiom, relative to it, even more.  People 
would probably start to use the "optimization" in general code, too.

In short, I would not over-emphasize the issue of ugly string 
composition in current LO, and rather live with it until we come up with 
something substantially better, benefiting all use cases, in LO 4.

> >    We'll probably wait until either all relevant compilers
> > support C++11's new character types, or we incompatibly change
> > rtl::OUString to UTF-8 (whatever happens first).
>
>         Which would be wonderful :-) I'm cheering that on. Having said that -
> if we go with gcc for cross-compile to Windows too, does that help us ?

The "Unicode String Literals" row at 
<wiki.apache.org/stdcxx/C++0xCompilerSupport> suggests so.  But then 
again, we still depend on MSVC for Windows builds as of now.

> > For types.rdb, my vision is to either use an XML format or, IMO even
> > better, a new .idl format that is (a) less verbose (why the heck all
> > those ";" in there, etc.?) and (b) does not rely on a preprocessor.
> > Then, a types.rdb could effectively be just one large .idl file.
>
>         Great. Of course, types.rdb being huge and empty would be fine if we
> didn't load and read it at startup a lot ;-) IIRC one use-case there was
> the lack of in-lined property Name/Value struct ->  any conversions, so:
>
> pArg.Name = rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "foo" ));
> pArg.Value<<= ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "baa" ));
>
>         Is nice&  efficient, and in-line-able; until that pArg ends up inside
> an Any itself - at which point we suck in types.rdb, start loading type
> data, inferring C++ structure offsets, and so on - just to allocate and
> construct the local Any (which I assume we could do&  in-line at compile
> time).

The Any operator <<= for complex structures uses a generic 
(introspective) approach.  I guess that was mainly done to keep the code 
small (esp. given that anything else would have had to be inline-only).

>         Then again - perhaps we use introspection for something else more
> serious on startup, or perhaps I'm out of date on this. Do you have a
> feel for whether it is just a few silly cases like this that we could
> work around ? or if there is some deep reason that types.rdb should be
> necessary at startup ?

Any sort of bridging probably requires introspection already (and Kay's 
purpose-bridges are still used early on, IIRC).  Getting types.rdb out 
of the picture here could be done either via "comprehensively compiled" 
.hpp headers (that contain the type information in C code; but that 
would probably bloat the code if done everywhere) or replacing generic 
(introspective) algorithms with per-type-templated ones (that would 
again bloat the code).  Difficult to tell whether true benefit lurks 
there...

Stephan