Re: C++ Variant type for DBus object path



Hi Kjell,

On 2015.04.08. 18:08, Kjell Ahlstedt wrote:
A reply, at long last! I have filed bug https://bugzilla.gnome.org/show_bug.cgi?id=747508 with a patch that 
I think fixes your problem.

It would be fine if you could test the patch with your quite complicated type of Variant. Can you apply and 
test a patch without great trouble? 
Thanks for the patch, I'll try it later and will let you know about the results.

If not, I can send you updated versions of the glibmm/variant.h and variant.cc files.
No need, thanks, patch is enough for me.


Kjell

Den 2015-03-31 13:43, Andrejs Hanins skrev:
Hi,

     Currently in Glibmm GDBus it seems no straightforward way to dynamically cast VariantBase containing 
some signature with object paths (o) into strictly typed Variant container. I faced the problem when 
interpreting (casting) the result of standard DBus org.freedesktop.DBus.ObjectManager.GetManagedObjects() 
method call which return signature is a{oa{sa{sv}}} (note 'o'). Typed Variant in my code is defined like 
this:

     Glib::Variant<std::map<Glib::ustring, std::map<Glib::ustring, std::map<Glib::ustring, 
Glib::VariantBase>>>>

but the Glib::VariantBase::cast_dynamic fails with bad_cast, because the type signature of the typed 
Variant is a{sa{sa{sv}}}, thats is, object 'o' is replaced with just 's'.

     My question - is there some ready-to-use type which can be used as a parameter of Variant<> template 
to specify that the Variant holds an object path, not just ordinary string?

     Of course, it is possible to create such a class in the client code like this (pseudo code):

class obj_path_t : public Glib::ustring;

template<>
class Variant<obj_path_t> : public Variant<Glib::ustring>
{
    static const VariantType& variant_type() { return VARIANT_TYPE_OBJECT_PATH; }
};

so that typed Variant looks like this:

     Glib::Variant<std::map<obj_path_t, std::map<Glib::ustring, std::map<Glib::ustring, 
Glib::VariantBase>>>>

and it actually works for me (cast_dynamic is OK), but IMO it should be provided by the Glibmm itself. Did 
I overlook something? Or this is just a missing feature?


BR, Andrey




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]