Re: Thoughts on Variant creation

[José Alburquerque <jaalburquerque gmail com>]

On Sat, 2012-12-22 at 13:47 -0800, Andrew Potter wrote:
> I've been thinking about how we create variants in glibmm and why its
> more of a pain than in C. The common case ultimate goal of variants is
> to throw a data structure into a tuple. In C, you can use
> g_variant_new() and a format string, and hand it pointers to your hard
> data. 1 method returns the desired result if you don't need to build a
> container variant. 
> 
> 
> However, currently in glibmm you have to call a ::create() method for
> each individual data element before you can call create_tuple(). It is
> relatively cumbersome for nontrivial tuples.
> 
> 
> There are a lot of possible solutions, but I have no idea which is the
> best. We could make a really bare wrapper g_variant_new() that passes
> all the arguments through and just Glib::wrap()s the result into a
> Glib::VariantContainerBase. Or, we could parse the format string
> ourselves and call the appropriate ::create() methods.
> 
> 
> Maybe we could break ground with a C++11 std::tuple constructor. It'd
> be really, really nice if you could just:
> 
> 
> auto vtuple = VariantContainerBase::create_tuple({(int) item1, (float)
> item2, (std::map) item3});
> 
> 
> Thoughts?

One possible solution might be to have a temporary limited tuple class
in glibmm along with a Glib::Variant<> class for it until c++-11 is
widely available.  I'm not sure what that would involve.

> 
> Also, what is the motivation to provide only ::create() methods and
> not do a constructor, e.g.:
> 
> 
> int i = 5;
> Variant<int> vint(i); 
> 

I think it's because GVariant is reference counted and generally
create() methods are used in that case.  I'm not sure why using
constructors that way would not be possible.

> Thanks for your time
> 
> 
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtkmm-list

-- 
José