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 736620 - GQueue: accept NULL sibling for insert_before() and insert_after()
GQueue: accept NULL sibling for insert_before() and insert_after()
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
unspecified
Other All
: Normal enhancement
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2014-09-13 14:54 UTC by Sébastien Wilmet
Modified: 2014-11-10 17:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GQueue: accept a NULL sibling for insert_before() and insert_after() (3.52 KB, patch)
2014-11-05 13:19 UTC, Sébastien Wilmet
reviewed Details | Review
Simplify code that uses g_queue_insert_before() and insert_after() (2.49 KB, patch)
2014-11-05 13:19 UTC, Sébastien Wilmet
committed Details | Review
GQueue: accept a NULL sibling for insert_before() and insert_after() (3.71 KB, patch)
2014-11-09 19:43 UTC, Sébastien Wilmet
committed Details | Review

Description Sébastien Wilmet 2014-09-13 14:54:18 UTC
For g_queue_insert_before(), it would be nice to allow a NULL sibling to push at the tail of the queue.

For g_queue_insert_after(), a NULL sibling could push at the head of the queue.

I can write the (simple) patch if you agree that it would be useful.
Comment 1 Sébastien Wilmet 2014-11-03 20:34:55 UTC
Any thoughts on this?

It would simplify a little bit some code in the undo/redo implementation in GtkSourceView, so it isn't just for a theoretical use case. (the use case in GtkSourceView is that we store a GList pointer to the current history location in the undo/redo GQueue. When we insert a new node it's relative to the location pointer, which can be NULL for the end of the queue).
Comment 2 Allison Karlitskaya (desrt) 2014-11-03 20:39:56 UTC
I agree that this makes sense.
Comment 3 Sébastien Wilmet 2014-11-05 13:19:39 UTC
Created attachment 290018 [details] [review]
GQueue: accept a NULL sibling for insert_before() and insert_after()

It simplifies a little bit some code that inserts data relative to a
GList location, that might be NULL for the tail of the queue. A NULL
sibling is probably less useful for insert_after(), so it's more for
consistency with insert_before().
Comment 4 Sébastien Wilmet 2014-11-05 13:19:45 UTC
Created attachment 290019 [details] [review]
Simplify code that uses g_queue_insert_before() and insert_after()

g_queue_insert_before() and g_queue_insert_after() now accept a NULL
sibling.
Comment 5 Allison Karlitskaya (desrt) 2014-11-09 15:49:28 UTC
Review of attachment 290018 [details] [review]:

::: glib/gqueue.c
@@ +1008,3 @@
+  else
+    {
+      queue->head = g_list_insert_before (queue->head, sibling, data);

begs the question: why not fix GList in the same way as well?
Comment 6 Sébastien Wilmet 2014-11-09 15:53:50 UTC
g_list_insert_before() already supports a NULL sibling, but it runs in O(n) time, while in GQueue it's always O(1).
Comment 7 Allison Karlitskaya (desrt) 2014-11-09 16:33:30 UTC
(In reply to comment #6)
> g_list_insert_before() already supports a NULL sibling, but it runs in O(n)
> time, while in GQueue it's always O(1).

Also: we'd need to update the tail pointer in that case...

Can you add a comment about these two points?  Otherwise looks good.
Comment 8 Sébastien Wilmet 2014-11-09 19:43:59 UTC
Created attachment 290286 [details] [review]
GQueue: accept a NULL sibling for insert_before() and insert_after()

It simplifies a little bit some code that inserts data relative to a
GList location, that might be NULL for the tail of the queue. A NULL
sibling is probably less useful for insert_after(), so it's more for
consistency with insert_before().
Comment 9 Allison Karlitskaya (desrt) 2014-11-10 04:37:43 UTC
Review of attachment 290286 [details] [review]:

Thanks
Comment 10 Allison Karlitskaya (desrt) 2014-11-10 04:37:56 UTC
Review of attachment 290019 [details] [review]:

and thanks again
Comment 11 Sébastien Wilmet 2014-11-10 17:10:51 UTC
Pushed, thanks for the review.