You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The std::map could potentially be very large. Perhaps it is not a problem in practice due to IPC overhead overshadowing cost of copying. I think Glib::Variant* is reference counted so perhaps copying is negligible (GVariant definetely is, but not sure if Glibmm wrapped class does a deep copy of the underlying GVariant or not).
@mardy@kursatkobya@jonte Any experience with using signals with complex types and large values in the generator? Pondering if this is worth looking into or not.
So cost of copying complex container types is reference counting on all elements. And in this particular case, copies of std::string (backing used for Glib::ustring) for the keys.
But in this case I'm not sure we can: I don't see much room to improve the sub side, because it needs anyway to copy those values into the VariantBase objects. But making the parameters const references does makes sense in any case.
As for the proxy side, yes, I think we can save a copy in the emission of the local signal if we mark its parameters to be const references.
Perhaps not that bad for a string, but e.g. have a signal that results in something like this in:
*_proxy.h:
sigc::signal<void, Glib::DBusObjectPathString, std::map<Glib::ustring,Glib::VariantBase>> Foo_signal;
*_proxy.cpp:Proxy::handle_signal():
*_stub.cpp:
Should perhaps add const & or && and std::move for non simple types where applicable.
The text was updated successfully, but these errors were encountered: