[Interest] Support for multiple 'out' parameters in qdbusxml2cpp

[Matt Hoosier]

Hi Thiago,

Thanks for replying. I'd traced through the logic in qdbusxml2cpp's source
as well before posting, and saw the same chunk of logic that determines
whether to emit only the placeholder.

Okay, I agree that I could pin down the parent class name and get automatic
dispatch wired up. But I'd like to understand why the normal
QMetaObject::invokeMethod() dispatch isn't allowed in this case (that is,
more than one 'out' parameter). At about line 1026 of a recent Git copy, we
have:

    bool usingInvokeMethod = false;

    if (parentClassName.isEmpty()
        && method.inputArgs.count() <= 10
        && method.outputArgs.count() <= 1)

        usingInvokeMethod = true;

    if (usingInvokeMethod) {
        ...
        // emits code to do QMetaObject::invokeMethod(parent(), ...);
        ...
    } else {
        // The behavior you cited earlier, where either parent()->method()
is directly
        // called or the placeholder YourObjectType code is used
    }

The test up top there forbids the generated code from ever using
QMetaObject::invokeMethod() if there's more than one output argument for
the D-Bus method. Why's that? The MOC doesn't generally have any trouble
plumbing up calls using arbitrarily many arguments, including non-const ref
types that would be used to pass down "out" parameters.

-Matt


On Fri, Jul 26, 2013 at 3:45 PM, Thiago Macieira
<thiago.macieira at intel.com>wrote:

> On sexta-feira, 26 de julho de 2013 15:27:21, Matt Hoosier wrote:
> > I've observed that qdbusxml2cpp doesn't emit the QMetaCall that would
> > forward a D-Bus method-call message from the adaptor along to the
> "business
> > logic" class that provides slots to implement all the various methods.
> > E.g., if I have:
> >
> >   <method name="Foo">
> >     <arg name="inValue" direction="in" type="s"/>
> >     <arg name="outValue1" direction="out" type="s"/>
> >     <arg name="outValue2" direction="out" type="s"/>
> >   </method>
> >
> > the adaptor code for this method ends up looking like:
> >
> >   ...
> >   public Q_SLOTS:
> >     QString MyInterfaceAdaptor::Foo(const QString &inValue, QString
> > &outValue2)
> >     {
> >         // handle method call MyInterfaceAdaptor.Foo
> >         //return static_cast<YourObjectType *>(parent())->Hello(inValue,
> > outValue);
> >     }
> >
> > Is there a design reason behind this? I examined the source to
> > qdbusxml2cpp, and it doesn't give any rationale why this type of call
> isn't
> > marshaled through a QMetaObject::invokeMethod() call the same as the
> > others. Passing the additional 'out' parameters as by-ref variables would
> > seem straightforward enough.
>
> Hi Matt
>
> According to the source code, the comment comes from:
>
>                 if (parentClassName.isEmpty())
>                     cs << "    //";
>                 else
>                     cs << "    ";
>
> and it later shows:
>                 if (parentClassName.isEmpty())
>                     cs << "static_cast<YourObjectType *>(parent())->";
>                 else
>                     cs << "parent()->";
>
> The presence of "YourObjectType" in the output you pasted to us confirms
> the
> analysis.
>
> The reason why it's commented out is that you didn't tell qdbusxml2cpp what
> the parent class type is. It can't write the code that will make the call
> without that information.
>
> You should pass the -l argument to qdbusxml2cpp, which sets the parent
> class
> name. (option -c was taken to mean the name of the class that qdbusxml2cpp
> is
> generating and -p was taken to mean the name of the file for the "proxy"
> class,
> which is the old name for what we now call the "interface" class).
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130726/97f48b49/attachment.html>