Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


On Thursday 25 of April 2013, Michael Stahl wrote:
On 25/04/13 12:08, Noel Grandin wrote:
On 2013-04-25 11:59, Michael Stahl wrote:
e.g. this problem here caused a 3 % or so slowdown in ODF file load
and/or save (i forgot which), mainly due to 2 additional queryInterface
calls in a critical place:
https://issues.apache.org/ooo/show_bug.cgi?id=108161

with your proposal it would be possible to write code like:

   Reference<B> b = ...
   methodFooThatTakesA( b );
   methodBarThatTakesA( b );
   methodBazThatTakesA( b );

... and get 3 queryInterface calls instead of 1.

or let me reformulate that: is it possible to implement your
hypothetical operator such that it does not call queryInterface (i don't
know).

 A and B are normal C++ classes with the right inheritance, aren't they? I'd 
expect a template uno::Reference ctor with the right check for allowing only 
inheriting types should do.

My desire is to make the UNO code less "noisy".
And it matches the natural semantics of C++, which is that it's possible
to pass a subtype of the expected parameter's type.

hmmm... looking at the amount of boilerplate involved one gets the
impression that UNO somehow appears more natural in languages that
aren't C++ :)

 Probably nobody has spent enough time to design that boilerplate for those 
other languages :).

-- 
 Lubos Lunak
 l.lunak@suse.cz

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.