Hi, Am Dienstag, den 22.09.2009, 15:23 +0200 schrieb Krzesimir Nowak: > > In Cluttermm animate is defined as: > > Glib::RefPtr< Animation > animate (gulong mode, unsigned int duration, > > const std::map< std::string, Glib::ValueBase > &properties)a
Eeek, it's a bad idea to have that in the API. Glib::ValueBase and the Glib::Value<> specializations are part of the internal infrastructure of the C++ bindings. It was never intended to be directly exposed in our API. To all C++ binding developers: Please do not create APIs which require application developers to deal with Glib::Value<> or Glib::ValueBase directly. This is wrong. The Glib::Value<> specializations exist in order to make it easy to provide a decent C++-style interface on top of them. What the C++ API will look like depends entirely on the specific functionality that is to be provided. There is *no* generic way to wrap APIs using GValue. Not even the C API uses GValue as the primary interface for application developers. For an example of correct use of Glib::Value<>, see the metadata classes Gtk::TreeModelColumn<> and Gtk::TreeModelColumnRecord in gtkmm, which provide a statically type-safe C++ interface to the tree model data. Another example is Gtk::Widget::get_style_property(), which allows convenient access to the style properties by name, but without the static type-safety guarantees provided by the Gtk::TreeModelColumn<> API. Neither of these substantially different design approaches expose the Glib::Value<> and Glib::ValueBase types visibly in the public API. The construction and initialization behavior of Glib::ValueBase and Glib::Value<> is rather peculiar and intentionally follows the C API closely. It is not possible to use Glib::Value<> objects in a generic manner like any other value type, particularly not as elements of STL containers. > Probably something like this: > > std::map<std::string, Glib::ValueBase> props; > std::pair<std::string, Glib::ValueBase> prop_pair; > > // Glib::Value<float> inherits from Glib::ValueBase. > Glib::Value<float> x, y; > x.set(100); > y.set(100); > prop_pair.first = "x"; > prop_pair.second = x; > props.insert(prop_pair); > prop_pair.first = "y"; > prop_pair.second = y; > props.insert(prop_pair); > my_animation->animate(my_mode, my_duration, props); It would look roughly like that if Glib::ValueBase had actually been designed as public API. The code will fail because the GValue is in an invalid state until ValueBase::init() has been called. Even if the example code would work as shown, it would still be a horrible API. It would be ridiculously verbose compared to the C interface, but still without any type safety advantage! You'd be better off using the C API. Let's try to avoid introducing something like a Variant type in the C++ bindings. And Glib::Value<> is most definitely not that variant type. Cheers, --Daniel _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
