# redis-plus-plus: a C++ Redis client that hinges on one hiredis copy > redis-plus-plus wraps the C library hiredis so C++ services get connection pooling, cluster, sentinel, pipeline and coroutine support in STL-like types. Its build is governed by two constraints stated plainly: exactly one hiredis copy on the machine, and one compiler standard shared with your application. **sewenew/redis-plus-plus** — Redis client written in C++ - Repository: https://github.com/sewenew/redis-plus-plus - Stars: 1,987 · Forks: 391 - Language: C++ - License: Apache-2.0 - Published: 2026-10-14 · Updated: 2026-10-14 · Language: en - Canonical page: https://hysenlabs.com/projects/sewenew-redis-plus-plus ## hiredis does the RESP work, redis-plus-plus shapes the types The repository describes itself as a Redis client written in C++, and the build needs a second library that you install first: hiredis. Nothing in this project replaces hiredis. That C library owns the socket and the RESP (REdis Serialization Protocol) frames on the wire, and the C++ wrapper sits above it to hand back C++ values, which is why the feature list advertises STL-like interfaces rather than a raw reply callback. The same layering explains the reach past Redis itself. Because the contract at the socket is RESP, the client also works with Valkey, DragonflyDB and KeyDB. The advertised surface runs from ordinary to elaborate: most Redis commands, a connection pool, Redis scripting, publish/subscribe, pipeline, transaction, Redis Cluster, Redis Sentinel, the generic command interface, Redis Stream, Redlock, Redis ACL, TLS/SSL support, a synchronous and an asynchronous interface, and a coroutine interface. Thread safety is the stated default position, qualified by the words unless otherwise stated, and the feature list never names which entries sit under that exception. ## One hiredis copy on the machine, or link errors with no named cause Before anything else, the project repeats one warning: do not install multiple versions of hiredis. The stated consequence stays deliberately vague, a warning about weird problems, and the text sends readers to issue 135, issue 140 and issue 158 as examples instead of describing the failure. That is thin ground for anyone assembling a build container, where a packaged copy and a self-compiled copy can share one include path without either announcing itself. Nothing in the installation section describes a version guard, so the rule stays a matter of following it by hand. Building the version you need from source is the documented route, and it installs into /usr/local by default. The four commands below clone hiredis, compile it and install it there. ```bash git clone https://github.com/redis/hiredis.git cd hiredis make sudo make install ``` If you want hiredis somewhere other than /usr/local, the same make commands carry a PREFIX argument, and the value has to reach the cmake configure step later so the compiler finds those headers. ```bash make PREFIX=/non/default/path make PREFIX=/non/default/path install ``` ## The v0.12.1 floor sits below what the async interface requires Two dependency statements in one document do not line up. The minimum version requirement for hiredis is v0.12.1, and the newest stable build of hiredis is what the project recommends. A few lines further down, the same section says async support needs hiredis v1.0.0 or later. The feature list still advertises a Sync and Async interface as a headline capability, so a reader who stops at the stated minimum ends up with a configuration that cannot deliver half of that line item. The easy route is named outright: install hiredis with a C++ package manager, with the Debian-style package given as the example. ```bash sudo apt-get install libhiredis-dev ``` That shortcut hands you whatever version the distribution froze, and no line in the installation section says which packaged versions are new enough for the async interface. Check the package version before relying on it, or build the version you need from source as shown above. ## Since 1.3.0 the default build is C++17, not the advertised C++11 The Overview says the library is compatible with C++11 and later versions, which reads like a floor you can build on. The default is different. Since version 1.3.0, the build uses the -std=c++17 standard so the code can rely on std::string_view and std::optional. Choose -std=c++11 or -std=c++14 instead and the project substitutes its own simple implementation of those two types, so the same header names resolve to different code depending on the flag. The rule that follows is stricter than it first reads. Build redis-plus-plus with one standard and your application with the same standard, because the project calls out a mismatch between the two as a mistake. For a codebase still pinned below C++17, opting back means carrying those substitute types until the whole application moves. Picking the standard is a cmake flag rather than an environment variable, and it sits alongside the two prefix options used above: ```bash cmake -DCMAKE_PREFIX_PATH=/path/to/hiredis -DCMAKE_INSTALL_PREFIX=/path/to/install/redis-plus-plus -DREDIS_PLUS_PLUS_CXX_STANDARD=11 .. ``` Leave the flag out and you get the -std=c++17 default. ## Cloning, cmake, and installing into a prefix of your choice redis-plus-plus is built with cmake, and the installation path is a clone, a build directory, a configure step, a compile and an install. There is no binary package for Linux in the repository tree, so this sequence is the whole documented install. ```bash git clone https://github.com/sewenew/redis-plus-plus.git cd redis-plus-plus mkdir build cd build cmake .. make sudo make install cd .. ``` Two cmake variables decide where everything lands. CMAKE_PREFIX_PATH points at the hiredis you installed, and CMAKE_INSTALL_PREFIX sets the destination for redis-plus-plus, which otherwise installs into /usr/local like hiredis does. Note that the install step ends with sudo, so the library ends up in a system-wide location unless you override that prefix. ```bash cmake -DCMAKE_PREFIX_PATH=/path/to/hiredis -DCMAKE_INSTALL_PREFIX=/path/to/install/redis-plus-plus .. ``` Consumers already on cmake can skip the install step entirely with the FetchContent feature, which pulls the sources at configure time, and the project points at pull request 639 as a worked example. ## Two libraries, position independent static code, and a test binary A default build produces more than one artifact, which matters when build minutes are the constraint. Both a static library and a shared library are built unless one is switched off, and the static library is compiled with -fPIC so it can be linked into a shared object later. The flag `-DREDIS_PLUS_PLUS_BUILD_STATIC_WITH_PIC=OFF` reverses that last choice. Compiling redis-plus-plus also compiles a test program, and the project warns that this might take a while. `-DREDIS_PLUS_PLUS_BUILD_TEST=OFF` removes it from the build entirely, on the same cmake command line as the prefix settings: ```bash cmake -DCMAKE_PREFIX_PATH=/path/to/hiredis -DCMAKE_INSTALL_PREFIX=/path/to/install/redis-plus-plus -DREDIS_PLUS_PLUS_BUILD_TEST=OFF .. ``` Two CI configurations sit side by side in the same tree, `.travis.yml` and `.github/`, and behaviour is exercised from `test/`. No separate documentation or examples directory exists, which leaves `README.md` as the single place where the API is described. The repository carries an Apache-2.0 `LICENSE` file at the top level, and the last push landed on 2026-08-04. ## Windows rides on Visual Studio 2017 cmake, flagged by its author Windows support reaches this client through the same dependency chain. hiredis has Windows support now, and Visual Studio has had built-in cmake support since Visual Studio 2017, so there is no separate generator story to learn. The coverage claim is specific about platform and version: fully tested with Visual Studio 2017 and later on Win 10. The author qualifies it immediately, writing that he is not familiar with the Visual Studio environment and that the following doc might not be accurate, then inviting readers on that platform to correct it. The section ends at links to Microsoft's cmake guidance. Windows is therefore the one platform where the instructions stop short of a complete command sequence, unlike the Unix path, which is given line by line. ## When hiredis on its own is the smaller choice The wrapper is not the only way to reach Redis from a C++ service. hiredis is a separate C library with its own build and its own install location, and a project that already links it can call it directly rather than adding a C++ layer on top. The difference in approach is what this library contributes: STL-like interfaces over the replies, a connection pool, publish/subscribe, pipeline, transaction, Redis Cluster, Redis Sentinel, the generic command interface, Redis Stream, Redlock, Redis ACL, TLS/SSL support, an asynchronous interface and a coroutine interface. That layer has a price. It adds a compiler standard constraint that must match your application, a build that compiles a test program, and a dependency pinned to exactly one installed version. Call hiredis directly when the job is a single command with no pool, no cluster and no pub/sub. Take the wrapper when those abstractions are what the service actually leans on, and when you can hold a single hiredis version in your build image. ## Conclusion Adopt redis-plus-plus when your C++ service needs pooling, cluster, sentinel, pipeline or coroutine support and you would rather not assemble those on the C API yourself, because that abstraction layer is where the value sits. Skip it for a one-off command, and for a codebase pinned below C++17 unless you accept the substitute std::string_view and std::optional. Before anything else, check which hiredis version your package manager hands you: the async interface needs v1.0.0 or later, while the stated floor is v0.12.1. ## FAQ ### What do I need before I can build redis-plus-plus? hiredis first, at v0.12.1 or later, and exactly one version of it on the machine. The library itself is compiled with cmake and installed with `sudo make install`; the project warns that installing multiple versions of hiredis leads to problems it does not detail. ### Does redis-plus-plus still build with C++11? Yes, but not by default. Since version 1.3.0 the default standard is `-std=c++17`, and building with `-std=c++11` or `-std=c++14` makes the library fall back on its own simple implementation of std::string_view and std::optional. Your application must be compiled with the same standard as the library. ### Can redis-plus-plus talk to Valkey, DragonflyDB or KeyDB? The Overview names them as compatible because they support RESP, the same serialisation protocol redis-plus-plus speaks to Redis. No per-server version matrix or test results for those three appear in the documentation. ### Does redis-plus-plus support Redis Cluster, Sentinel and pub/sub? The feature list names Redis Cluster, Redis Sentinel, Redis publish/subscribe, pipeline, transaction, Redis Stream, Redlock and Redis ACL. Its table of contents also breaks out Redis Modules, an async interface and a coroutine interface as their own sections. ### How do I skip the test program that the build compiles? Pass `-DREDIS_PLUS_PLUS_BUILD_TEST=OFF` to cmake. Two other options drop unwanted artifacts: `-DREDIS_PLUS_PLUS_BUILD_STATIC=OFF` and `-DREDIS_PLUS_PLUS_BUILD_SHARED=OFF`, since a default build produces both a static and a shared library. ## Sources - [Issues](https://github.com/sewenew/redis-plus-plus/issues) - [License: Apache-2.0](https://github.com/sewenew/redis-plus-plus/blob/master/LICENSE) - [README](https://github.com/sewenew/redis-plus-plus/blob/master/README.md) - [Releases](https://github.com/sewenew/redis-plus-plus/releases) - [sewenew/redis-plus-plus on GitHub](https://github.com/sewenew/redis-plus-plus) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sewenew-redis-plus-plus