After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 783209 - Replace GLib typedefs with standard C++ ones
Replace GLib typedefs with standard C++ ones
Status: RESOLVED OBSOLETE
Product: glibmm
Classification: Bindings
Component: general
2.53.x
Other Linux
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2017-05-29 18:57 UTC by Daniel Boles
Modified: 2018-05-22 12:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Replace GLib’s gsize with C++’s std::size_t (96.58 KB, patch)
2017-05-29 22:15 UTC, Daniel Boles
none Details | Review

Description Daniel Boles 2017-05-29 18:57:40 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.
Comment 1 Daniel Boles 2017-05-29 22:15:53 UTC
Created attachment 352831 [details] [review]
Replace GLib’s gsize with C++’s std::size_t
Comment 2 Daniel Boles 2017-05-29 22:22:19 UTC
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.
Comment 3 GNOME Infrastructure Team 2018-05-22 12:12:56 UTC
-- 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.