bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: modules for generic unordered sets and mappings


From: Jim Meyering
Subject: Re: RFC: modules for generic unordered sets and mappings
Date: Fri, 02 Jul 2010 13:34:21 +0200

Paolo Bonzini wrote:
> On 07/02/2010 01:37 AM, Bruno Haible wrote:
>> Apropos hash tables.
>>
>> For some years now, we have generic lists in gnulib. "Generic" means that the
>> programmer can switch the implementation easily, because he's programming
>> against an abstract API that has a number of different implementations.
>>
>> Here is my draft for applying the same approach to unordered sets. The normal
>> implementation would be a hash table, but there are important variations:
>>    - Is the key a pointer, or a memory block of arbitrary size?
>>    - Is the value stored, or implicit?
>>    - Does inserting a (key,value) pair make a copy of the key?
>>    - Does the table allow removals?
>>
>> Feedback is highly appreciated! Do you see some interesting use case that I
>> have overlooked?
>
> I disagree that all these should be in gnulib.

Why not?
The only justification I can infer from your message is via
your mention of "cost".  Are you concerned about run-time cost,
disk space cost, maintenance cost or some other?

However, I would welcome Bruno's proposed sets and mappings.
Just because they're initially added to gnulib does not mean
they can never become independent libraries.

> In fact, I think ADTs
> don't belong there.  libunistring and crypto stuff are borderline
> already (because some of the modules actually make sense in gnulib,
> e.g. uniwidth and sha1), but these should be in a shared library, not
> a static one.

Think of gnulib as an incubator.
Some parts may eventually migrate out to become their own
separate libraries once they are mature and if they are used
widely enough.

> In fact, glib or libnih probably provide all that you need already,
> and they're always loaded on a modern Linux system so their cost is
> effectively zero.  (Then, getting stuff into glib is a royal pain in
> the ass).

Not everyone can depend on "glib" being installed.
Are you seriously suggesting that one of those libraries become
a prerequisite of fundamental packages like find, tar and coreutils?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]