Thank you once again to all who have responded. I have changed my mind. I DO grasp the nature of responders' objections. My understanding has now reached a "tipping point". What is the tipping point? On 03/21/2016 04:30 PM, Behdad Esfahbod
wrote:
Matthias, I comprehend what you are saying here. As Christian pointed out recently (https://mail.gnome.org/archives/gtk-devel-list/2016-March/msg00037.html), "DRY alone is not a sufficient argument."
The tipping point is the function g_utf8_normalize() - which is called by objects which DO possess a length-of-string in units of UTF 8-code-points ("characters" in Glib parlance). If my proposed idea were to be adopted in a useful way - then every call to any g_utf8_*() function would require that it be wrapped in a g_ustring_*() [previously g_utf8_string_*()] function in order for GUString [previously G_UTF8String] to be truly useful. Time to move on. Along the way - however - I have come up with two functions which I will be proposing and which may very well be useful in a number of certain cases: g_utf8_unilen() - which measures the length of string in UTF-8 sequences ("characters") primarily and in non-nul bytes secondarily g_utf8_offset_to_pointer_sized () - which optimizes its return value by by first comparing byte length to UTF-8 length [for the cases when these are both known] - opting for pointer arithmetic when equal - and then compares UTF-8 offset to UTF-8 length in order to decide whether to parse the first 3/4 of the last 1/4 when calling g_utf8_offset_to_pointer() These last two, I will definitely be submitting as a patch. |