public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Toebs Douglass <toby@winterflaw.net>
To: libc-help <libc-help@sourceware.org>
Subject: Re: Linked List Implementation
Date: Mon, 27 Nov 2017 16:38:00 -0000	[thread overview]
Message-ID: <582fb0d8-cfa2-71ae-c315-a07a71042daa@winterflaw.net> (raw)
In-Reply-To: <cac7a2d7-6edf-2790-1bee-ab673a038a04@redhat.com>

On 27/11/17 16:22, Florian Weimer wrote:
> On 11/27/2017 01:19 PM, Toebs Douglass wrote:
>> I'd love to find some new ideas, things I've totally missed, use cases 
>> I had no idea about.
> 
> There's some disagreement whether inline allocation of keys/values needs 
> to be supported,

Inline?  do you mean by this inside the data structure function calls?

> whether key/value pointers should be void *,

What are the alternatives?

> and whether the allocator should be tied to malloc/free.

If the user handles allocation, this problem is solved, because it is up 
to the user.

As it is, NUMA alone makes allocation inside a data structure ugly, 
because you have to pass in so many parameters.

In general though the user benefit hugely from being able to allocate 
from the stack or heap, or globals; when I stopped doing allocation 
inside data structures, it seemed to me absolutely clearly the right 
thing to do - resource allocation is a different and separate task.

> Some people prefer 
> macros which generate function definitions,

Hard to follow in a debugger.  Code should look like it is.

> others prefer function 
> pointers (sometimes with a closure argument, sometimes without).

Do you mean function pointers for the API functions?  stored in say the 
state structure?

> Some 
> are strictly opposed to aliasing violations which happen to work today, 
> others want strict language conformance.

I'm not sure I've ever run into aliasing issues... why would you benefit 
from doing so / what would you be doing for it to occur anyway?

> For individual data structures, the level of configuration offered 
> varies greatly.  Not everyone things a custom resize policy is necessary 
> for arrays or hash tables, or you need to be able to choose between 
> different conflict resolution strategies in hash tables.

Yes, but this doesn't matter - data structures in what they offer, as 
opposed to how they are implemented (macros, allocation, etc), vary.  A 
list is not a tree.  It's fine to have many different data structures 
which offer different things.

> Some people want C++ compatibility, others are strictly opposed to it.

I've heard of "Clean C", which can be compiled in C++ mode, where the 
compiler can optimize more thoroughly.  That seems nice.

> Those are just he issues that come to my mind immediately.

Heh!

I've clearly been living under the stairs for a long time :-)

  reply	other threads:[~2017-11-27 16:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-27  1:27 Charlie Sale
2017-11-27  8:02 ` tomas
2017-11-27 12:02 ` Florian Weimer
2017-11-27 12:19   ` Toebs Douglass
2017-11-27 16:22     ` Florian Weimer
2017-11-27 16:38       ` Toebs Douglass [this message]
2017-11-27 16:56         ` Florian Weimer
2017-11-27 15:19   ` Charlie Sale

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=582fb0d8-cfa2-71ae-c315-a07a71042daa@winterflaw.net \
    --to=toby@winterflaw.net \
    --cc=libc-help@sourceware.org \
    /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).