This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Linked List Implementation
- From: Toebs Douglass <toby at winterflaw dot net>
- To: libc-help <libc-help at sourceware dot org>
- Date: Mon, 27 Nov 2017 12:19:22 +0000
- Subject: Re: Linked List Implementation
- Authentication-results: sourceware.org; auth=none
- References: <CAPzG3iajbq4y=tOXMpzPuN67Z2A8U4Vh8guwhH-_HQpKv7hQDQ@mail.gmail.com> <fa92a41d-f479-b28e-a248-014a6da57cb3@redhat.com>
On 27/11/17 12:02, Florian Weimer wrote:
These interfaces are old and somewhat difficult to use, but I expect it
will be difficult to get consensus for a new set of interfaces because
everyone looks for something different in a container library.
As a data structure developer, I'm very interested to find out what
other people are expecting from APIs.
For me, there is a struct for state, a struct per element, each element
has two void pointers, one to the key, one to the value. The
per-element struct is normally a member of the user struct which is to
placed into data structure, the the value is set to be the address of
that user data structure.
The caller performs all allocations, so he can use heap, stack, globals,
etc.
There's an init() and a cleanup() for the main state struct, and the
data structure functions themselves (link to list, insert to btree, etc,
depending on the data structure).
Where reasonably possible, APIs are macros, as often very little work is
being done.
Data structures are either single threaded, and the user handles
locking, or lock-free (in which case, heaven help us all :-)
And that's it - that's what I've come to, after all these years.
I'd love to find some new ideas, things I've totally missed, use cases I
had no idea about.