Wrapper libraries (or library wrappers) consist of a thin layer of code (a "shim") which translates a library's existing interface into a compatible interface. This is done for several reasons:

• To refine a poorly designed or complicated interface
• Allow code to work together which otherwise cannot (e.g. incompatible data formats)
• Enable cross language and/or runtime interoperability

Wrapper libraries can be implemented using the adapter, façade, and to a lesser extent, proxy design patterns.

The specific way in which a wrapper library is implemented is highly specific to the environment it is being written in and the scenarios which it intends to address. This is especially true in the case when cross-language/runtime interoperability is a consideration.

The following provides a general illustration of a common wrapper library implementation over a C POSIX library header <pthread.h> (for POSIX threads, or "pthreads"). In this example, a C++ interface acts as a "wrapper" around a C interface.

In <pthread.h>:

#include <sys/types.h>

// previous declarations...
int pthread_mutex_init(pthread_mutex_t* mutex , const pthread_mutexattr_t* attr);
int pthread_mutex_destroy(pthread_mutex_t* mutex);
int pthread_mutex_lock(pthread_mutex_t* mutex);
int pthread_mutex_unlock(pthread_mutex_t* mutex);
// more functions...

Wrapping <pthread.h> with PosixThread.cppm:

export module org.posix.PosixThread;

import <pthread.h>;

export namespace org::posix {

// previous wrappers...

class ThreadMutex {
private:
    ::pthread_mutex_t mutex;

    friend class ThreadLock;

    void lock() noexcept {
        ::pthread_mutex_lock(&mutex);
    }

    void unlock() noexcept {
        ::pthread_mutex_unlock(&mutex);
    }
public:
    ThreadMutex() {
        ::pthread_mutex_init(&mutex, 0);
    }

    ~ThreadMutex() {
        ::pthread_mutex_destroy(&mutex);
    }
};

class ThreadLock {
private:
    ThreadMutex& mutex;
public:
    explicit ThreadLock(ThreadMutex& mutex): 
        mutex{mutex} {
        mutex.lock();
    }

    ~ThreadLock() {
        mutex.unlock();
    }
};

// more wrappers...

}

The original C interface can be regarded as error prone, particularly in the case where users of the library forget to unlock an already locked mutex. The new interface effectively utilizes resource acquisition is initialization (RAII) in the new org::posix::ThreadMutex and org::posix::ThreadLock classes to ensure org::posix::ThreadMutexs are eventually unlocked and pthread_mutex_t objects are automatically released.

The above code closely mimics the implementation of boost::scoped_lock and boost::mutex classes from Boost which are part of the Boost.Thread library.

Some wrapper libraries exist to act as a bridge between a client application and a library written using an incompatible technology. For instance, a Java application may need to execute a system call. However system calls are typically exposed as C library functions. To resolve this issue Java implements wrapper libraries which make these system calls callable from a Java application.

In order to achieve this, languages like Java provide a mechanism called foreign function interface that makes this possible. Some examples of these mechanisms include:

• Java Native Interface (JNI) and Java Foreign Function and Memory API
• Java Native Access (JNA)
• ctypes (Python module)
• Managed Extensions
• SWIG (Simplified Wrapper and Interface Generator)
• std::ffi (Rust)
• cxx library (Rust-C++ interop)

Some examples of existing wrapper libraries:

• Pthreads for WIN32
• OpenGL Bindings for Python
• MySQL++
• JavaCV
• WineD3D

• Wrapper function
• Wrapper pattern
• Glue code