Skip to content
This repository

A standalone and lightweight C library

branch: master

Merge pull request #31 from jmarshall/warnings

Silence -Wstrict-prototypes and static analyser warnings in klist.h
latest commit 28c6d83079
Heng Li lh3 authored
Octocat-spinner-32 lua change to 0 indexed array June 03, 2011
Octocat-spinner-32 test change the argument ordering October 11, 2013
Octocat-spinner-32 .gitignore Add kputw() and kputl() tests July 22, 2013
Octocat-spinner-32 README.md Spelling / grammar corrections in the README. February 01, 2013
Octocat-spinner-32 bgzf.c minor changes October 28, 2011
Octocat-spinner-32 bgzf.h improved backward compatibility October 28, 2011
Octocat-spinner-32 kbit.h some basic bit operations April 08, 2012
Octocat-spinner-32 kbtree.h Change /2 to >>1. Surprisingly this improves the speed... January 16, 2011
Octocat-spinner-32 kgraph.h Graph related routines. Unfinished. DON'T USE! December 28, 2011
Octocat-spinner-32 khash.h Document -1 extra return code in kh_put(). July 13, 2013
Octocat-spinner-32 khmm.c Added the khmm library January 13, 2011
Octocat-spinner-32 khmm.h Added the khmm library January 13, 2011
Octocat-spinner-32 klist.h Silence -Wstrict-prototypes and static analyser warnings April 09, 2014
Octocat-spinner-32 kmath.c computed Kolmogorov-Smirnov's D January 03, 2013
Octocat-spinner-32 kmath.h merge kmin.*, kfunc.c and krand.* to kmath.* July 17, 2012
Octocat-spinner-32 knetfile.c for g++ compatibility June 06, 2012
Octocat-spinner-32 knetfile.h Added the knetfile library January 13, 2011
Octocat-spinner-32 knhx.c print tree in the Newick format December 18, 2012
Octocat-spinner-32 knhx.h print tree in the Newick format December 18, 2012
Octocat-spinner-32 kopen.c invoke a shell when necessary January 15, 2012
Octocat-spinner-32 ksa.c Constructing suffix array for multi-sentinel str. August 19, 2011
Octocat-spinner-32 kseq.h bugfix: empty fasta/q lines cause troubles April 15, 2012
Octocat-spinner-32 ksort.h Update ksort.h November 29, 2013
Octocat-spinner-32 kstring.c Merged with attractivechaos/klib: July 17, 2013
Octocat-spinner-32 kstring.h removed incorrect comments July 24, 2013
Octocat-spinner-32 ksw.c bugfix: point address changes February 20, 2013
Octocat-spinner-32 ksw.h added NW and SW-extension; backported from bwa February 12, 2013
Octocat-spinner-32 kthread.c added a more flexible scheduler; not tested October 11, 2013
Octocat-spinner-32 kthread.h forgot the header file November 02, 2013
Octocat-spinner-32 kurl.c don't seek when opening December 07, 2013
Octocat-spinner-32 kurl.h allow to feed change key/secret/id-file November 21, 2013
Octocat-spinner-32 kvec.h Two bugs reported by istreeter and wanghc78 January 26, 2013
README.md

Klib: a Generic Library in C

Overview

Klib is a standalone and lightweight C library distributed under MIT/X11 license. Most components are independent of external libraries, except the standard C library, and independent of each other. To use a component of this library, you only need to copy a couple of files to your source code tree without worrying about library dependencies.

Klib strives for efficiency and a small memory footprint. Some components, such as khash.h, kbtree.h, ksort.h and kvec.h, are among the most efficient implementations of similar algorithms or data structures in all programming languages, in terms of both speed and memory use.

Common components

Components for more specific use cases

Methodology

For the implementation of generic containers, klib extensively uses C macros. To use these data structures, we usually need to instantiate methods by expanding a long macro. This makes the source code look unusual or even ugly and adds difficulty to debugging. Unfortunately, for efficient generic programming in C that lacks template, using macros is the only solution. Only with macros, we can write a generic container which, once instantiated, compete with a type-specific container in efficiency. Some generic libraries in C, such as Glib, use the void* type to implement containers. These implementations are usually slower and use more memory than klib (see this benchmark).

To effectively use klib, it is important to understand how it achieves generic programming. We will use the hash table library as an example:

#include "khash.h"
KHASH_MAP_INIT_INT(m32, char)        // instantiate structs and methods
int main() {
    int ret, is_missing;
    khint_t k;
    khash_t(m32) *h = kh_init(m32);  // allocate a hash table
    k = kh_put(m32, h, 5, &ret);     // insert a key to the hash table
    if (!ret) kh_del(m32, h, k);
    kh_value(h, k) = 10;             // set the value
    k = kh_get(m32, h, 10);          // query the hash table
    is_missing = (k == kh_end(h));   // test if the key is present
    k = kh_get(m32, h, 5);
    kh_del(m32, h, k);               // remove a key-value pair
    for (k = kh_begin(h); k != kh_end(h); ++k)  // traverse
        if (kh_exist(h, k))          // test if a bucket contains data
            kh_value(h, k) = 1;
    kh_destroy(m32, h);              // deallocate the hash table
    return 0;
}

In this example, the second line instantiates a hash table with unsigned as the key type and char as the value type. m32 names such a type of hash table. All types and functions associated with this name are macros, which will be explained later. Macro kh_init() initiates a hash table and kh_destroy() frees it. kh_put() inserts a key and returns the iterator (or the position) in the hash table. kh_get() and kh_del() get a key and delete an element, respectively. Macro kh_exist() tests if an iterator (or a position) is filled with data.

An immediate question is this piece of code does not look like a valid C program (e.g. lacking semicolon, assignment to an apparent function call and apparent undefined m32 'variable'). To understand why the code is correct, let's go a bit further into the source code of khash.h, whose skeleton looks like:

#define KHASH_INIT(name, SCOPE, key_t, val_t, is_map, _hashf, _hasheq) \
  typedef struct { \
    int n_buckets, size, n_occupied, upper_bound; \
    unsigned *flags; \
    key_t *keys; \
    val_t *vals; \
  } kh_##name##_t; \
  SCOPE inline kh_##name##_t *init_##name() { \
    return (kh_##name##_t*)calloc(1, sizeof(kh_##name##_t)); \
  } \
  SCOPE inline int get_##name(kh_##name##_t *h, key_t k) \
  ... \
  SCOPE inline void destroy_##name(kh_##name##_t *h) { \
    if (h) { \
      free(h->keys); free(h->flags); free(h->vals); free(h); \
    } \
  }

#define _int_hf(key) (unsigned)(key)
#define _int_heq(a, b) (a == b)
#define khash_t(name) kh_##name##_t
#define kh_value(h, k) ((h)->vals[k])
#define kh_begin(h, k) 0
#define kh_end(h) ((h)->n_buckets)
#define kh_init(name) init_##name()
#define kh_get(name, h, k) get_##name(h, k)
#define kh_destroy(name, h) destroy_##name(h)
...
#define KHASH_MAP_INIT_INT(name, val_t) \
    KHASH_INIT(name, static, unsigned, val_t, is_map, _int_hf, _int_heq)

KHASH_INIT() is a huge macro defining all the structs and methods. When this macro is called, all the code inside it will be inserted by the C preprocess to the place where it is called. If the macro is called multiple times, multiple copies of the code will be inserted. To avoid naming conflict of hash tables with different key-value types, the library uses token concatenation, which is a preprocessor feature whereby we can substitute part of a symbol based on the parameter of the macro. In the end, the C preprocessor will generate the following code and feed it to the compiler (macro kh_exist(h,k) is a little complex and not expanded for simplicity):

typedef struct {
  int n_buckets, size, n_occupied, upper_bound;
  unsigned *flags;
  unsigned *keys;
  char *vals;
} kh_m32_t;
static inline kh_m32_t *init_m32() {
  return (kh_m32_t*)calloc(1, sizeof(kh_m32_t));
}
static inline int get_m32(kh_m32_t *h, unsigned k)
...
static inline void destroy_m32(kh_m32_t *h) {
  if (h) {
    free(h->keys); free(h->flags); free(h->vals); free(h);
  }
}

int main() {
    int ret, is_missing;
    khint_t k;
    kh_m32_t *h = init_m32();
    k = put_m32(h, 5, &ret);
    if (!ret) del_m32(h, k);
    h->vals[k] = 10;
    k = get_m32(h, 10);
    is_missing = (k == h->n_buckets);
    k = get_m32(h, 5);
    del_m32(h, k);
    for (k = 0; k != h->n_buckets; ++k)
        if (kh_exist(h, k)) h->vals[k] = 1;
    destroy_m32(h);
    return 0;
}

This is the C program we know.

From this example, we can see that macros and the C preprocessor plays a key role in klib. Klib is fast partly because the compiler knows the key-value type at the compile time and is able to optimize the code to the same level as type-specific code. A generic library written with void* will not get such performance boost.

Massively inserting code upon instantiation may remind us of C++'s slow compiling speed and huge binary size when STL/boost is in use. Klib is much better in this respect due to its small code size and component independency. Inserting several hundreds lines of code won't make compiling obviously slower.

Resources

  • Library documentation, if present, is available in the header files. Examples can be found in the test/ directory.
  • Obsolete documentation of the hash table library can be found at SourceForge. This README is partly adapted from the old documentation.
  • Blog post describing the hash table library.
  • Blog post on why using void* for generic programming may be inefficient.
  • Blog post on the generic stream buffer.
  • Blog post evaluating the performance of kvec.h.
  • Blog post arguing B-tree may be a better data structure than a binary search tree.
  • Blog post evaluating the performance of khash.h and kbtree.h among many other implementations. An older version of the benchmark is also available.
  • Blog post benchmarking internal sorting algorithms and implementations.
  • Blog post on the k-small algorithm.
  • Blog post on the Hooke-Jeeve's algorithm for nonlinear programming.
Something went wrong with that request. Please try again.