From: Bruno Haible <bruno@clisp.org>
To: bug-gnulib@gnu.org
Cc: "Marc Nieper-Wißkirchen" <marc.nieper+gnu@gmail.com>
Subject: Re: Node to first or last element of a sequential list in module list/xlist
Date: Sat, 03 Apr 2021 00:49:37 +0200 [thread overview]
Message-ID: <1933730.XpJS2eiqJP@omega> (raw)
In-Reply-To: <CAEYrNrTx5dzA9AefJ9aMag7ptOV_FKWZ4yaqjr4Y7-t7S3Y6qg@mail.gmail.com>
Hi Marc,
> At the moment, there does not seem to be an easy way to retrieve the node
> of the first or the last element in a list.
The purpose of the gl_list_node_t is to write algorithms that work
efficiently with linked-lists, when it is necessary (for performance)
to hold a reference to a linked-list node that is far from the first and
far from the last linked-list node.
For the first and the last node in a list, there is no such performance
problem. Hence what you ask for is not needed.
> This is useful if the list has to be traversed while nodes are added
> because an iterator cannot be used here.
I don't understand. You want to use a list_node_t while adding nodes to
the list? This is invalid, since the comments in gl_list.h say:
/* Type representing the position of an element in the list, in a way that
is more adapted to the list implementation than a plain index.
Note: It is invalidated by insertions and removals! */
typedef struct gl_list_node_impl * gl_list_node_t;
> What is currently possible is to use get_first/set_first (and
> get_last/set_last) to get hold of the first (and last) node but this is
> clearly a hack.
>
> Another way to get hold of the first node is to create an iterator and to
> call its next procedure just once. But this is overkill if the iterator
> isn't used afterward.
Yes these are two existing ways to do what you want. An iterator is a
small stack-allocated object; it is designed for being created and then
thrown away soon afterwards.
> What I want to propose is to allow the NULL value in
> gl_next_node/gl_previous_node. In this case, gl_next_node shall return the
> first node and gl_previous_node shall return the last node.
It's not useful to extend an API
- for a rare fringe use-case,
- when there are already two other ways to do what you ask for (with the
same O(·) performance).
Bruno
next prev parent reply other threads:[~2021-04-02 22:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-02 15:52 Node to first or last element of a sequential list in module list/xlist Marc Nieper-Wißkirchen
2021-04-02 22:49 ` Bruno Haible [this message]
2021-04-03 7:03 ` Marc Nieper-Wißkirchen
2021-04-03 9:49 ` Bruno Haible
2021-04-03 10:00 ` Marc Nieper-Wißkirchen
2021-04-03 10:14 ` Bruno Haible
2021-04-03 10:26 ` Marc Nieper-Wißkirchen
2021-04-03 16:28 ` Bruno Haible
2021-04-03 16:46 ` Marc Nieper-Wißkirchen
2021-04-03 16:55 ` Bruno Haible
[not found] ` <CAEYrNrTatLc1QcBPzhbs9b64Dv5P5J7HuR+Tj8o6QKh91u1jZw@mail.gmail.com>
2021-04-04 23:30 ` Bruno Haible
2021-04-05 10:20 ` Marc Nieper-Wißkirchen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1933730.XpJS2eiqJP@omega \
--to=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=marc.nieper+gnu@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).