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

Bug#604338: marked as done (RFP: libhashish -- powerful and generic hash library for C and C++)



Your message dated Thu, 23 Feb 2017 22:20:06 +0000
with message-id <E1ch1k6-0006pT-DV@quantz.debian.org>
and subject line closing RFP: libhashish -- powerful and generic hash library for C and C++
has caused the Debian Bug report #604338,
regarding RFP: libhashish -- powerful and generic hash library for C and C++
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
604338: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604338
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: wnpp
Severity: wishlist

* Package name    : libhashish
  Version         : 1.0
  Upstream Author : Hagen Paul Pfeifer <hagen@jauu.net>
* URL             : http://libhashish.sf.net/
* License         : GPLv2
  Programming Lang: C
  Description     : powerful and generic hash library for C and C++

Libhashish is a powerful and generic hash library for C and C++. The library
attempt to combine the best algorithms in this area and take all kinds of
optimizations into account. Furthermore the main focus is applicability - at
least you should use and feel comfortable with this library.
.
 * Built-in key support for char arrays (strings) and uint_{8,16,32} types,
   support for own (possible complex) key data types
 * Support rbtrees as collision strategy instead of bucked lists (avoid worst
   case O(n) scenario)
 * Dynamic or manual adjustable table size (reordering if proportion
   entries/table_size is unfavorable)
 * Iterator support (equivalent to ruby's hash.each() method)
 * Thread clean - fine-grained lock mechanisms (mutex locks, reader writer
   locks, ...)
 * Bloom filter implementation
 * Many built-in hash algorithms (from trivial to cryptographic algorithms)
 * As lightweight as possible - no bloated code



--- End Message ---
--- Begin Message ---
RFP 604338 has no visible progress for a long time, so closing.

--- End Message ---

Reply to: