GNOME Bugzilla – Bug 783209
Replace GLib typedefs with standard C++ ones
Last modified: 2018-05-22 12:12:56 UTC
GLib has typedefs because of its desire to support ancient C Standards, and more typedefs that have no purpose... other than, I guess, 'so that they all consistently start with g and can by syntax-highlighted in extremely old emacs'. glibmm and co should not be bound by the same historical baggage: we're aiming for pretty cutting-edge C++, using newly Standardised features relatively soon after they debut. Therefore, it would be more appropriate to use the idiomatic C++ types: either the basic ones where the pointless GLib typedefs are used (guint, gchar, etc.) or the more specialised ones where specific sizes are requested - std::size_t, std::(u)INTNN_t, etc. My proposal is therefore to replace such types with their standard C++ counterparts wherever possible. Some of this is cut and dry: gint, guint, gchar, etc. => int, unsigned int, unsigned char, etc. gsize => std::size_t guint8, gint32, etc. => std::uint8_t, std::int32_t, etc. No danger of any ABI breaks there (even though in most cases we can now do so with impunity!) However, there are one or two cases that may give us pause for thought. For example, gssize is meant to be equivalent to the POSIX type ssize_t, basically 'like size_t except it might also be negative, or at least -1'... https://stackoverflow.com/questions/8649018/what-is-the-difference-between-ssize-t-and-ptrdiff-t We would probably get away with using std::ptrdiff_t, but I'm not sure anything is strictly guaranteed here. So this one is more up for debate.
Created attachment 352831 [details] [review] Replace GLib’s gsize with C++’s std::size_t
I also have a patch that replaces all typedefs of basic types (gchar, gint, gpointer, etc.) with the normal names, and it works. However, I'd like to pore over it a bit more to make sure I'm happy with the semantics of it. Particularly in the code that actually interfaces with C functions, it might be better to keep the g* types just to be extra explicit about the fact we're calling C functions. Do you think so, or would you prefer to use the non-g* types wherever possible? ...at least until we might replace all of those with auto, so no one will have any idea what types they are either way. ;-) Certainly I personally would say that the most (or perhaps the only really) important thing is to replace the g* types in the mm API - i.e. if readers can see gwhatever in the wrapped documentation, then IMO that's undesirable. However, I don't want to steam ahead (more than I already have) without having a clear consensus on what should be changed.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glibmm/issues/18.