Re: Proposal: make Glib::Property much more flexible

A Glib::Property with less restrictions would be nice, if possible, especially if it's possible without breaking ABI or API.

There is a serious threat hanging over Glib::Property, described in the bugs (glib) (gtkmm)

If the glib bug, preventing the installation of properties after class_init, is implemented, I don't understand how any custom properties can be added in a reasonable way in glibmm or gtkmm.

If the glib developers decide to implement bug 698614, it's perhaps not worth spending much time on a better Glib::Property class.


2014-06-06 05:35, Povilas Kanapickas skrev:

Currently Glib::Properties are limited by being required to be direct data members of the containing class object. Unfortunately, this makes impossible to use Glib::Property in most exported C++ APIs as additions or removals of Glib::Property members break the ABI. The issue could be solved by using the PIMPL idiom, but as of now this is not possible.

The direct data member requirement arises from the way property ids are used to map to property wrappers. At the moment we depend on the layout of objects of some type always having the same layout, which is guaranteed by the C++ standard. This allows us to define the property id as the offset of the property wrapper sub-object from the start of the parent object.

I propose to depend on a different invariant that would greatly increase the flexibility of Glib::Property and would allow to use them as members of PIMPL structs. C++ standard guarantees that all sub-objects of the given class are always initialized in the same order. We can employ this to define the property id as the number of already (re)installed properties during the construction of the current object. The addresses of the property wrappers could be stored in a separate, per object array. The property id could be used to retrieve the address of the property wrapper from that array.

We actually use this approach already for properties that are overridden by interfaces (see commit ce20003fd in glibmm). In this email I propose to use the same mechanics for non-overridden properties too.

This way the direct data member limitation would be lessened to only requiring the user to always construct the same number of properties in the same order, which wouldn't be an issue in almost all cases. In particular, the PIMPL idiom could be used for properties too.

If there's consensus among glibmm developers that this is a reasonable improvement, I volunteer to implement a patch and test it extensively.

All the best,

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