[Dbus-cxx-users] RE : MessageAppendIterator::operator<< begin called instead of overload defined in global namespace

[<emm...@or...>]

Hello,

Here's a patch to the example code so that it triggers the compilation error.
Apparently, overload resolution in Message::operator<< chooses ::operator<<( DBus::MessageAppendIterator&, const SomeType& ), while it prefers the less specific DBus::MessageAppendIterator::operator<<(const T&) in MethodProxy<...>::operator().
However messageappenditerator.h is included before either methods are even declared (I checked the preprocessor output) so I would expect the compiler to have the same behavior in both of them.

I also tried forward-declaration of class MessageAppendIterator and operator<<(DBus::MessageAppendIterator&, struct timeval) before including any dbus-cxx headers but that would not work either. Moving the user-defined operator<< to the DBus namespace also solves nothing, so it does not seem to be a problem with function name lookup.

I find myself puzzled.

--
Emmanuel
________________________________________
De : Robert Middleton [rmi...@sy...]
Date d'envoi : mercredi 20 novembre 2013 04:31
À : RAULO-KUMAGAI Emmanuel NRS
Cc : dbu...@li...
Objet : Re: [Dbus-cxx-users] MessageAppendIterator::operator<< begin called instead of overload defined in global namespace

Interesting observation, I'm guessing that what's going on is because of how the includes are being parsed, the second parameter is being compiled as a separate compilation unit or something.  Could you attach the sources that you've been using to test this?  I think I understand what you're saying but I want to be sure.

One possible solution would be to not use operator<< and operator>> in order to do serialization/deserialization.  Personally, I'm not a fan of overloading operators, but it works so I haven't done anything with it.  I almost think that maybe the best solution here would be to re-design how the messages are built up, so that it would be possible to add in different types of appenders into the system - as it stands right now, defining custom types is rather convoluted(and apparently prone to errors).

-Robert Middleton


On Mon, Nov 18, 2013 at 9:03 AM, <emm...@or...<mailto:emm...@or...>> wrote:
Hello,

Lately, I have been playing around with DBus-cxx and user-defiend types.

When working with custom types in DBus-cxx, I found that MethodProxy::operator() will call the template member operator<< in MessageAppendIterator instead of the user-defined overload in the global namespace *starting*with*the*second*method*parameter*.
MessageAppendIterator::operator<< in turn attempts to call the MessageAppendIterator::append overload which does not exist and raises a compiler error. This happens at least with GCC 4.6.3

The bug can be reproduced by slightly modifying the time client/server example in examples/basics/types. Just add *two* dummy parameters of type struct timeval to the now() method to trigger this.

As a fix, I propose that MessageAppendIterator::operator<< be modified to delegate its implementation to a template struct with a static append() method. The user would then have to specialize this struct instead of defining his/her own operator<< for custom types. Lazy instantiation of operator<< would ensure that the appropriate specialization is used.

This would also have the benefit of allowing one partial specialization to be used for a broad range of types. As an example, I'm using this to automatically serialize introspectable types (e.g. through boost::enable_if<is_introspectable<T>>::type).

Please see attached patch for the proposed solution. This is a patch against dbus-cxx 0.8.0.

By the way, it would also be nice if deserialization also worked that way. Maybe serialization, deserialization and signature could all rely on a single traits structure as a default?

Regards,

--
Emmanuel
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
Dbus-cxx-users mailing list
Dbu...@li...<mailto:Dbu...@li...>
https://lists.sourceforge.net/lists/listinfo/dbus-cxx-users



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.