Hi José,
> I think that I may be mixing two different things:
> set membership and searching in the contents of the set. I will try
> to clarify myself:
>
> - A membership function would get an element and would return a
> boolean indicating whether the element is contained in the set. A
> s
Jim Meyering wrote:
> I think the goal of this function is to return the single (first?)
> KEY-matching entry from the set ...
> ...
> Think of set of composite values (a struct), of which
> one serves as a key. You may want to query whether a
> dummy { key, x, y, z } is in the set, solely to find
> An unordered set is effectively a mapping between a key and a boolean
> (membership) so I am not sure what would be the benefit of returning
> something like 'gl_set_node_t' instead of the boolean directly. In
> case we want to change the membership status for some key then we
Jose E. Marchesi wrote:
>
> >gl_set_search O(n) O(1)
> >
> >Here the search method returns a void *, with value (void*)-1
> >denoting "not found". Hmm, or should the search method better
> >take a 'bool *' argument???
> >
>
>gl_set_search O(n) O(1)
>
>Here the search method returns a void *, with value (void*)-1
>denoting "not found". Hmm, or should the search method better
>take a 'bool *' argument???
>
> If 'gl_set_search' is merely t
Jose E. Marchesi wrote:
>gl_set_search O(n) O(1)
>
>Here the search method returns a void *, with value (void*)-1
>denoting "not found". Hmm, or should the search method better
>take a 'bool *' argument???
>
> If 'gl_set_search' is merely testing t
gl_set_search O(n) O(1)
Here the search method returns a void *, with value (void*)-1
denoting "not found". Hmm, or should the search method better
take a 'bool *' argument???
If 'gl_set_search' is merely testing the membership of an element in a
set
On 07/02/2010 04:01 PM, Bruno Haible wrote:
Hi Paolo,
Maintenance and, secondarily, RAM cost.
RAM cost? Do you think linking with a shared library with 100 modules costs
less RAM than having 5 of these modules linked in the executable? Also, do
you frequently run 'm4' at the same time as you
Hi Paolo,
> I disagree that all these should be in gnulib. In fact, I think ADTs
> don't belong there.
Why not? The '*-list' modules are used by gettext, m4, pdf, the 'clean-temp'
module, git-merge-changelog. They clearly satisfy the gnulib entry criterion
of " "portability" and/or common files
Paolo Bonzini wrote:
...
>>> 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.
>>
>> Not everyone can depend on "glib" being installed.
>> Are you seriously suggesting that one of those l
> 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?
Maintenance and, secondarily, RAM cost.
> However, I would welcome Bruno's proposed sets and mappings.
> Ju
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
On 07/02/2010 01:37 AM, Bruno Haible wrote:
Hi all,
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
Paul Eggert wrote:
> Table A is indexed by device number (a dev_t value)
> Table B is indexed by inode number
> The gnulib hash package uses void * keys, but having a void * value
> that exists only to point to an ino_t value wastes memory.
Eric Blake wrote:
> sizeof(ino_t) == 8
Jim Meyering wrot
Eric Blake wrote:
> On 07/01/2010 06:44 PM, Paul Eggert wrote:
>> I've just gone through "du", and it's fresh in my
>> mind, so I thought I'd run through what I needed there, to see how
>> well it maps to the proposal.
>>
>> I needed three kinds of hash tables.
>>
>> * Table A is indexed by device
Paul Eggert wrote:
...
>>Here the search method returns a void *, with value (void*)-1
>>denoting "not found". Hmm, or should the search method better take a
>>'bool *' argument???
>
> Whatever it is, it should be simple and fast.
>
> Also, there needs to be a fast and easy way to say "
Bruno Haible wrote:
> Hi all,
>
> 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
On 07/01/10 20:26, Eric Blake wrote:
> sizeof(void*) == sizeof(size_t) == 4, but sizeof(ino_t) == 8, and most
> inodes are quite randomly dispersed but definitely larger than 4 bytes.
> Does your scheme work well at mapping cygwin's 8-byte inodes into
> 4-byte pointers?
For those inode numbers t
On 07/01/2010 06:44 PM, Paul Eggert wrote:
> I've just gone through "du", and it's fresh in my
> mind, so I thought I'd run through what I needed there, to see how
> well it maps to the proposal.
>
> I needed three kinds of hash tables.
>
> * Table A is indexed by device number (a dev_t value) an
Paul Eggert writes:
> I needed three kinds of hash tables. [...]
PSPP has a simple kind of hash table that might suit your
purposes. Some people like its approach; others don't.
Here it is:
http://git.savannah.gnu.org/cgit/pspp.git/tree/src/libpspp/hmap.h
http://git.savannah.gn
I've just gone through "du", and it's fresh in my
mind, so I thought I'd run through what I needed there, to see how
well it maps to the proposal.
I needed three kinds of hash tables.
* Table A is indexed by device number (a dev_t value) and the value is a
secondary hash table. Typically the n
Hi all,
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 appr
22 matches
Mail list logo
