LaunchDarkly monorepo for C++ SDKs.

This repository contains LaunchDarkly SDK packages which are written in C++. This includes shared libraries, used by SDKs and other tools, as well as SDKs.

Packages

Readme	issues	tests	docs (C++)	docs (C)	latest release
libs/client-sdk	C++ Client SDK				On Github
libs/server-sdk	C++ Server SDK				On Github
libs/server-sdk-redis-source	C++ Server SDK - Redis Source				On Github

Shared packages	issues	tests
libs/common	Common
libs/internal	Internal
libs/server-sent-events	Common Server-Sent-Events

Organization

Directory	Description
.github	Contains CI and release process workflows and actions.
examples	Contains examples (hello-world style).
contract-tests	Contains contract test service.
cmake	Contains cmake files for importing and configuring external libraries.
libs	Contains library implementations. This includes libraries shared within the project as well as SDK libraries like the client-sdk.
scripts	Contains scripts used in the release process.
vendor	Contains third party source which is directly integrated into the project. Generally third party source is included through CMake using FetchContent, but some libraries require modification specific to this repository.

Build Requirements

Dependencies

1. C++17 and above
2. CMake 3.19 or higher
3. Ninja (if using the included build scripts)
4. Boost version 1.81 or higher (excluding Boost 1.83, see note below)
5. OpenSSL

Note

Boost 1.83 is not supported due to an incompatibility in Boost.JSON. This issue appears to be resolved in versions prior and subsequent to 1.83.

Additional dependencies are fetched via CMake. For details see the cmake folder.

GoogleTest is used for testing.

For information on integrating an SDK package please refer to the SDK specific README.

CMake Options

Various CMake options are available to customize the client/server SDK builds.

Option	Description	Default	Requires
BUILD_TESTING	Coarse-grained switch; turn off to disable all testing and only build the SDK targets.	On	N/A
LD_BUILD_UNIT_TESTS	Whether C++ unit tests are built.	On	BUILD_TESTING; NOT LD_BUILD_SHARED_LIBS
LD_TESTING_SANITIZERS	Whether sanitizers should be enabled.	On	LD_BUILD_UNIT_TESTS
LD_BUILD_CONTRACT_TESTS	Whether the contract test service (used in CI) is built.	Off	BUILD_TESTING
LD_BUILD_EXAMPLES	Whether example apps (hello world) are built.	On	N/A
LD_BUILD_SHARED_LIBS	Whether the SDKs are built as static or shared libraries.	Off (static lib)	N/A
LD_BUILD_EXPORT_ALL_SYMBOLS	Whether to export all symbols in shared libraries. By default, only C API symbols are exported because C++ does not have an ABI. Only use this feature if you understand the risk and requirements. A mismatch in ABI could cause crashes or other unexpected behaviors.	Off (hidden)	LD_BUILD_SHARED_LIBS
LD_DYNAMIC_LINK_BOOST	If building SDK as shared lib, whether to dynamically link Boost or not. Ensure that the shared boost libraries are present on the target system.	On (link boost dynamically when producing shared libs)	LD_BUILD_SHARED_LIBS
LD_DYNAMIC_LINK_OPENSSL	Whether OpenSSL is dynamically linked or not.	Off (static link)	N/A
LD_BUILD_REDIS_SUPPORT	Whether the server-side Redis Source is built or not.	Off	N/A
LD_CURL_NETWORKING	Enable CURL-based networking for all HTTP requests (SSE streams and event delivery). When OFF, Boost.Beast/Foxy is used instead. CURL must be available as a dependency when this option is ON.	Off	N/A
LD_BUILD_OTEL_SUPPORT	Whether the server-side OpenTelemetry integration package is built or not.	Off	N/A
LD_BUILD_OTEL_FETCH_DEPS	When building OpenTelemetry support, automatically fetch and configure OpenTelemetry dependencies via CMake FetchContent. This is useful for local development and CI. When OFF, you must provide OpenTelemetry yourself via find_package.	Off	LD_BUILD_OTEL_SUPPORT
LD_OTEL_CPP_VERSION	Specifies the OpenTelemetry C++ SDK version (git tag or commit hash) to fetch when LD_BUILD_OTEL_FETCH_DEPS is enabled. Can be set to any valid git reference from the opentelemetry-cpp repository.	ea1f0d61ce5baa5584b097266bf133d1f31e3607 (v1.23.0)	LD_BUILD_OTEL_FETCH_DEPS

Warning

When building shared libraries C++ symbols are not exported, only the C API will be exported. This is because C++ does not have a stable ABI. For this reason, the SDK's unit tests are not built in shared library mode.

Building the SDK from Source

To configure the SDK's CMake project:

# Use 'make' as the build system.
cmake -B build -S . -G"Unix Makefiles"

To pass in config options defined in the table above, add them using -D:

# Use 'make' as the build system, build shared libs, and disable testing.
cmake -B build -S . -G"Unix Makefiles" \
-DLD_BUILD_SHARED_LIBS=On \
-DBUILD_TESTING=Off ..

The example uses make, but you might instead use Ninja, MSVC, etc.

Building with CURL Networking

By default, the SDK uses Boost.Beast/Foxy for HTTP networking. To use CURL instead, enable the LD_CURL_NETWORKING option:

cmake -B build -S . -DLD_CURL_NETWORKING=ON

Warning

CURL support for the server-side SDK is currently experimental. It is subject to change and may not be fully tested for production use.

Proxy support does not apply to the redis persistent store implementation for the server-side SDK.

CURL Requirements by Platform

Linux/macOS: Install CURL development libraries via your package manager:

# Ubuntu/Debian
sudo apt-get install libcurl4-openssl-dev
# macOS
brew install curl

Windows (MSVC): CURL must be built from source using MSVC to ensure ABI compatibility. A helper script is provided:

.\scripts\build-curl-windows.ps1 -Version "8.11.1"-InstallPrefix "C:\curl-install"

Then configure the SDK with:

cmake -B build -S .-DLD_CURL_NETWORKING=ON `-DCURL_ROOT="C:\curl-install"`-DCMAKE_PREFIX_PATH="C:\curl-install"

The build-curl-windows.ps1 script:

• Downloads CURL source from curl.se
• Builds static libraries with MSVC using CMake
• Uses Windows Schannel for SSL (no OpenSSL dependency)
• Installs to the specified prefix directory

Note

Pre-built CURL binaries from curl.se (MinGW builds) are not compatible with MSVC and will cause linker errors.

Incorporating the SDK via add_subdirectory

The SDK can be incorporated into an existing application using CMake via add_subdirectory..

# Set SDK build options, for example:set(LD_BUILD_SHARED_LIBS On)
add_subdirectory(path-to-cpp-sdks-repo)
target_link_libraries(your-appPRIVATElaunchdarkly::client)
# ... or launchdarkly::server

Incorporating the SDK via find_package

Warning

Preliminary support for find_package is available. The package configuration is subject to change, do not expect it to be stable as long as this notice is present.

If you've installed the SDK on the build system via cmake --install, you can consume it from the target application like so:

find_package(launchdarklyREQUIRED)
target_link_libraries(your-appPRIVATElaunchdarkly::launchdarkly-cpp-client)
# ... or launchdarkly::launchdarkly-cpp-server

LaunchDarkly overview

LaunchDarkly is a feature management platform that serves trillions of feature flags daily to help teams build better software, faster. Get started using LaunchDarkly today!

Testing

We run integration tests for all our SDKs using a centralized test harness. This approach gives us the ability to test for consistency across SDKs. These tests cover each method in the SDK, and verify that event sending, flag evaluation, stream reconnection, and other aspects of the SDK all behave correctly.

Contributing

We encourage pull requests and other contributions from the community. Check out our contributing guidelines for instructions on how to contribute to this SDK.

About LaunchDarkly

• LaunchDarkly is a continuous delivery platform that provides feature flags as a service and allows developers to iterate quickly and safely. We allow you to easily flag your features and manage them from the LaunchDarkly dashboard. With LaunchDarkly, you can:
  • Roll out a new feature to a subset of your users (like a group of users who opt-in to a beta tester group), gathering feedback and bug reports from real-world use cases.
  • Gradually roll out a feature to an increasing percentage of users, and track the effect that the feature has on key metrics (for instance, how likely is a user to complete a purchase if they have feature A versus feature B?).
  • Turn off a feature that you realize is causing performance problems in production, without needing to re-deploy, or even restart the application with a changed configuration file.
  • Grant access to certain features based on user attributes, like payment plan (eg: users on the ‘gold’ plan get access to more features than users in the ‘silver’ plan). Disable parts of your application to facilitate maintenance, without taking everything offline.
• LaunchDarkly provides feature flag SDKs for a wide variety of languages and technologies. Read our documentation for a complete list.
• Explore LaunchDarkly
  • launchdarkly.com for more information
  • docs.launchdarkly.com for our documentation and SDK reference guides
  • apidocs.launchdarkly.com for our API documentation
  • blog.launchdarkly.com for the latest product updates