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


On 03/02/2012 11:35 AM, Michael Stahl wrote:
On 02/03/12 10:32, Michael Meeks wrote:
On Fri, 2012-03-02 at 09:29 +0100, Stephan Bergmann wrote:
Micheal, I think I still don't understand what you are up to here.  What
does logging have to do with XUnoTunnel ?

        Correct me if I'm wrong, but as soon as we start doing bridging - which
is necessary for logging - then instead of passing C++ object handles
around which will dynamic_cast<>  properly, we end up with some bridge
object in the middle instead, and all instances of dynamic_cast break -
is that right ? :-)

It depends. If the code that does the dynamic_cast is in the same UNO environment as the object being casted, then, thanks to UNO's short-circuiting, references to the UNO object are always direct pointers to the C++ object inside that environment.

So, looking at the common case where some UNO object C++ implementation (a) creates another "child" UNO object C++ implementation via new, (b) passes it out, and (c) obtains it back and uses XUnoTunnel or dynamic_cast to get at the child's implementation: this should continue to work even with the LogBridge. (Which, in turn, implies that the LogBridge does not log intra-environment calls among objects.)

   (And we want as little as possible of the XUnoTunnel hack, anyway,
so no idea what your "dynamic_cast<>  alike" idea is?)

the problem is that sometimes XUnoTunnel is necessary, e.g. you in our
applications where UNO is not used internally, but has been tacked on as
wrappers, you cannot implement a method that takes a parameter which is
from the same application and do anything useful with it without
XUnoTunnel (or dynamic_cast), because the UNO API (of course) does not
give access to (necessary) implementation details.

I've never given much thought to dynamic_cast vs. XUnoTunnel (at least I don't remember right now I ever did; searching old mail archives would probably prove me wrong) -- to me XUnoTunnel was always that rarely needed hack where the notational overhead doesn't really hurt. But sure, for the UNO wrappers in the application layers things look different. Anyway, thinking about it now, I see no reason one could not use dynamic_cast instead of XUnoTunnel in the scenario outlined above.

        Well - so - my wonder was whether we could create something much
lighter, that does XTunnel's job - built into the UNO core code itself,
and bypassing such bridges (with some suitable simple, pleasant and
readable syntax as dynamic_cast<>).

so you want an uno Reference that points at a (potentially) remote
object, but still want to get a C++ pointer to that?  i don't believe
there's a simpler solution than XUnoTunnel for this without giving up
safety.

So either dynamic_cast works, so you can use it, or it does not work, in which case there is apparently no way to (and no sense in) obtaining a plain C++ pointer to the object.

Make it into a "random UNO improvements" project?  Hm, not sure.

        ;-) well - as you like. IMHO it makes sense writing these things up in
some detail for people new to the project.

Makes sense for sure. Now only need to get that writer's block out of the way... ;)

hehe, to me it looks mmeeks just wants to get you to mentor anything at
all  ;)

Feels like that.  ;)

Stephan

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.