Re: [Dbus-cxx-devel] Patch to support vector of structures
Status: Beta
Brought to you by:
rvinyard
From: Tyler C. <tc...@ta...> - 2010-01-04 21:07:18
|
Thanks for incorporating that so quickly. Let me explain why I changed it from append to the overloaded "<< operator". My DBus interface needed to exposes a method with a structure for a return value. This structure had a couple of vectors of structures. I overloaded the "<< operator" for the return value structure as well as the structures for each vector type. When the vectors were being appended by the MessageAppendIterator it was calling Append on the structure, but of course it wasn't defined for my structure type. Changing it from append allowed me to create a "<< overload " for my structure. If I'm approaching this problem incorrectly please let me know (I'm new to this). I didn't see any examples where there was a vector of user defined structures so I tried to follow the existing design pattern. On 1/4/10 8:03 AM, "Rick L. Vinyard, Jr." <rvi...@cs...> wrote: Tyler Conant wrote: > 1. This is a diff against 0.5.0. The sub iter was not being set to NULL > during the deletion of the iter when closing the container. This was > causing an access error when creating a second child container. > I just pushed out 0.5.1 that fixes this bug. Thanks again for hunting this one down. > 2. To support structures the << operator is overloaded, but this did not > help with a vector of structures since the append operator was called on > the child iter, instead of the << operator. This change doesn't appear to > have any side effects, but I'm new to dbus-cxx and have yet to walk > through the entire code base. > - m_subiter->append( v[i] ); - + //m_subiter->append( v[i] ); + *m_subiter << v[i]; This one I'm not too clear on. I'm wondering if there is also something else going on. The overloaded << operator is very thin and is essentially: this->append( v ); As a result, m_subiter->append(v[i]); and *m_subiter << v[i]; should be equivalent unless there is something subtle going on in the resolution. --- Rick |