cppzmq wraps libzmq in two headers, and its tested platform list stops at Ubuntu 20.04 and Visual Studio 2019

Three things cppzmq changes about the libzmq C API

cppzmq is a C++ binding for libzmq, and its design goals are specific about what it fixes. The libzmq C API exposes various class-like concepts as void*, so cppzmq makes them type-safe. The C API reports failure through errno, so cppzmq uses exceptions. The C API requires the user to free resources explicitly, so cppzmq provides RAII-style classes that do it for you.

The core types are zmq::context_t, zmq::socket_t, zmq::socket_ref and zmq::message_t. Enums such as zmq::socket_type, zmq::sockopt, zmq::send_flags and zmq::recv_flags replace the integer constants of the C interface. The result types zmq::send_result_t and zmq::recv_result_t carry what send and recv return.

None of this changes the messaging model. Sockets, patterns and transports are still libzmq's, so the binding reads the same as ZeroMQ documentation written for C.

Two headers do the work, and only one of them stays close to the C API

The project calls itself light-weight and header-only. You only need to include zmq.hpp, and maybe zmq_addon.hpp, to use it. The split between them is deliberate. zmq.hpp is meant to contain direct mappings of the abstractions provided by the libzmq C API. zmq_addon.hpp provides additional higher-level abstractions.

In zmq_addon.hpp you find zmq::multipart_t and zmq::active_poller_t, plus the functions zmq::recv_multipart, zmq::send_multipart, zmq::send_multipart_n, zmq::encode and zmq::decode. In zmq.hpp you find the plain bindings, including zmq::poll, zmq::proxy, zmq::proxy_steerable, zmq::version, zmq::buffer and zmq::str_buffer, along with zmq::monitor_t for socket events.

Because there is no compiled library, there is no ABI of cppzmq to match. The link dependency is libzmq alone.

A push socket in eight lines, and a multipart example over a wildcard TCP port

The first example in the README needs at least C++11:

#include <zmq.hpp>

int main()
{
    zmq::context_t ctx;
    zmq::socket_t sock(ctx, zmq::socket_type::push);
    sock.bind("inproc://test");
    sock.send(zmq::str_buffer("Hello, world"), zmq::send_flags::dontwait);
}

The context owns the sockets, the socket type is an enum class value, and zmq::str_buffer wraps a string literal as a buffer. The dontwait flag makes send return instead of blocking.

The second example sends and receives multi-part messages over TCP. It binds a push socket to tcp://127.0.0.1:*, reads the chosen endpoint back with sock1.get(zmq::sockopt::last_endpoint), connects a pull socket to it, and sends an array of two zmq::const_buffer values. The examples directory holds more, and each one is compiled to an executable when tests are enabled.

The CI list is Ubuntu 18.04 and 20.04, Visual Studio 2017 and 2019, and macOS 10.15

The README is candid that only a subset of the platforms supported by libzmq itself are supported. Platforms with full support, meaning CI executes build and tests, are Ubuntu 18.04 x64 with gcc 4.8.5, 5.5.0 and 7.5.0, Ubuntu 20.04 x64 with gcc 9.3.0, 10.3.0 and clang 12, Visual Studio 2017 x64, Visual Studio 2019 x64, and macOS 10.15 with clang 12, without the DRAFT API.

The list of additional platforms known to work is empty. It says there are no current reports and invites readers to add theirs, with CI on a GitHub-compatible cloud service if possible. For other platforms, the README says any libzmq platform with gcc 4.8.1 or newer or clang 3.4.1 or newer probably works, as does Visual Studio 2012 and later on x86 or x64.

The consequence is plain. A current compiler on a current OS is outside the tested matrix, even though the repository was pushed to in October 2026.

Any libzmq 4.x is expected to work, but only two versions are tested

Compatibility with libzmq is stated as an expectation: any libzmq 4.x version is expected to work. The explicitly tested versions are 4.2.0, without the DRAFT API, and 4.3.4, with and without it.

DRAFT features need extra care. The README warns that they may only work for the most recent tested version. In the type list, three entries carry the DRAFT label in zmq.hpp (zmq::poller_t, zmq::event_flags and zmq::poller_event), and zmq::active_poller_t is DRAFT in zmq_addon.hpp. If your libzmq was built without the draft API, the poller classes are the part to check first.

The C++ requirement is also moving. Some features already require a compiler supporting C++11, and the README says that in the future, probably all features will require C++11. Code that still builds as C++03 should not assume the unconditional parts stay that way.

Building libzmq first, then cppzmq, or skipping both through vcpkg

The build instructions are two out-of-source CMake builds in sequence. First libzmq is cloned from github.com/zeromq/libzmq, built in a build directory with cmake .. and installed with sudo make -j4 install. Then cppzmq gets the same treatment:

git clone https://github.com/zeromq/cppzmq.git
cd cppzmq
mkdir build
cd build
cmake -DCPPZMQ_BUILD_TESTS=OFF ..
sudo make -j4 install

The -DCPPZMQ_BUILD_TESTS=OFF form skips the tests. Building them requires CMake and Catch.

The alternative is vcpkg. After cloning vcpkg and running ./bootstrap-vcpkg.sh (bootstrap-vcpkg.bat for Powershell), you run ./vcpkg integrate install and then ./vcpkg install cppzmq. The README then points to a CMake find package script, so find_package(cppzmq) works from your CMakeLists.txt. The repository also ships cppzmq.pc.in and cppzmqConfig.cmake.in for pkg-config and CMake consumers.

Where cppzmq differs from zmqpp, czmqpp and fbzmq

The README names three other C++ bindings for ZeroMQ and says none of them are header-only. zmqpp is a high-level binding to libzmq. czmqpp is a binding based on the high-level czmq API. fbzmq integrates with Apache Thrift, adds higher-level abstractions and requires C++14.

So the difference is where the abstraction level sits. cppzmq stays close to the libzmq C API in zmq.hpp and adds only a thin higher layer in zmq_addon.hpp. If you want an object model that hides ZeroMQ's socket vocabulary, those other bindings are what the README points you to. If you want to port C examples line by line, cppzmq is the closer match.

The README makes no performance or size comparison between them, and none is claimed here. The distinguishing facts it gives are header-only against not header-only, and the abstraction level.

Releases are two years apart, the macro surface is four names, and the last push was in October 2026

The recent releases are v4.9.0 on 9 October 2022, v4.10.0 on 20 June 2023 and v4.11.0 on 20 June 2025. The default branch is master, the licence is MIT, and the repository was last pushed to on 5 October 2026 and is not archived. The gap between releases means a fix merged to master can wait a long time for a tag, so pin a commit if you need one.

The compatibility guidelines are short. Consumers should not depend on any macro defined in cppzmq unless it is declared public, and the public macros are CPPZMQ_VERSION, CPPZMQ_VERSION_MAJOR, CPPZMQ_VERSION_MINOR and CPPZMQ_VERSION_PATCH. The README calls its list non-exhaustive.

Contributions follow the policy at rfc.zeromq.org/spec:22. For a longer API tour the README links Tour of CPPZMQ by @brettviren.

Editorial conclusion

Use cppzmq if you already depend on libzmq 4.x and want its C API as type-safe C++ with exceptions and RAII, installed by copying two headers or through CMake or vcpkg. Pick zmqpp, czmqpp or fbzmq instead if you want a high-level API, since cppzmq keeps zmq.hpp as a direct mapping. Before adopting it, check your compiler against the CI list in the README, because it names Ubuntu 18.04 and 20.04, Visual Studio 2017 and 2019 and macOS 10.15, and calls everything else untested.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. zeromq/cppzmq on GitHub