My understanding is that Glib::Value (and GValue for that matter) is something like boost::any, a container for values of arbitrary (well, not really) type. Given this, the API to me loks awkward in so many aspects, I thought I'd ask here about the reasoning behind some of the design choices:
1. As the docs state clearly, I'm supposed to explicitly call the init(GType) method to define the actual type of the value to be stored. Glib::Value<int> x; x.init(G_TYPE_INT); Why isn't the call to init() already part of the constructor? The way it is now seems totally unnecessary and error-prone to me. I do not see a reason for init() to be exposed in the public API at all. 2. Closely related to 1., copy constructor and copy assignment of Glib::Value<T> don't copy the GType. Again, I have to explicitly call init() for the destination value?? 3. Actually, looking at the relationship between Glib::ValueBase and the various Glib::Value<T> subclasses it seems the sole role of Glib::Value<T> is to provide an additional set(T x) method to set a value. So I'm wondering whether this inheritance hierarchy is actually needed at all? Why not just have a single (non-template) Glib::ValueBase class (could be called just Glib::Value) with a set(T x) *method* template? So essentially just like boost::any. Also, a Value(T x) constructor and operator=(const T x) would be nice. Dominique _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
