Re: [Libreoffice] uno discoverability

Hi Stephan,

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.

> It seems like all attempts at true improvement in this area always 
> collide with rtl::OUString being neither UTF-8 (i.e., layout compatible 
> with plain char) nor wchar_t (at least on Linux etc.; and using GCC's 
> -fshort-wchar would not help, as it breaks binary compatibility with 
> libstdc++).

        Yep; although getting the most-common cases of having slower, but
easy-to-use, and small-object-code helpers for printf & exceptions would
be really helpful IMHO :-)

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

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

        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 ?

        All the best,

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot