GitHub user darion-yaphet closed a discussion: Proposal: raise minimum C++
standard from C++11 to C++14
## Summary
I'd like to propose raising bRPC's **minimum / default C++ language standard
from C++11 to C++14**.
This is intentionally a **conservative** step: update the build defaults and
docs first, without a broad modernization refactor.
## Motivation
1. **C++14 is mature and widely available**
C++14 was standardized in 2014. Current CI (e.g. Ubuntu 22.04 / modern
macOS) and the compilers we already recommend (GCC 8.2+) support it without
issue.
2. **The C++11 / GCC 4.8 baseline is largely historical**
Docs still mention very old toolchains, but they also note that GCC 4.8
can only build up to older bRPC releases (e.g. 1.5.0). Keeping C++11 as the
official
floor no longer matches what we actually test and recommend.
3. **Dependency reality already moved past C++11**
Newer Protobuf versions require at least C++14, and bRPC already switches
to **C++17** when Protobuf >= 22 (for Abseil). A C++14 floor better matches the
ecosystem without jumping all the way to C++17 yet.
4. **Small but useful language/library completions**
C++14 mainly "completes C++11" (`std::make_unique`, generic lambdas,
relaxed `constexpr`, `_t` trait aliases, `[[deprecated]]`, etc.). This makes
future
maintenance easier; it is **not** being proposed for runtime performance
gains.
## Non-goals (for this proposal)
- No claim of meaningful runtime performance improvement from `-std=c++11` →
`-std=c++14` alone
- No large-scale API/ABI rewrite
- No mandatory cleanup of legacy helpers (`DISALLOW_COPY_AND_ASSIGN`,
homemade traits, etc.) in the same change
- Not waiting for a hypothetical 2.x release just to change the default
`-std=`
## Proposed scope (phase 1)
If there is consensus, follow up with a small PR that only:
- CMake: default `BRPC_CXX_STANDARD` 11 → 14
- `config_brpc.sh`: default `-std=c++0x` → `-std=c++14`
- Examples / docs: update `cxx_std_11` / `-std=c++11` mentions
- Document compiler expectation consistent with C++14 (e.g. GCC >= 5, while
still recommending GCC 8.2+)
- Release note: clearly call out the minimum standard change
Existing behavior should remain:
- Protobuf >= 22 path continues to use **C++17** (unchanged)
Optional later phases (separate PRs, only if desired):
- Gradually adopt C++14 features in new/touched code (`make_unique`, etc.)
## Compatibility impact
- Users already on modern compilers: effectively no impact
- Users still requiring pure C++11 / very old GCC: would need to stay on an
older bRPC release
- Header consumers would eventually need to compile as C++14+ once headers
start using C++14 features; phase 1 can keep that risk low by limiting changes
to build
defaults first
## Alternatives considered
1. **Keep C++11**
Lowest churn, but the documented floor keeps drifting away from
CI/dependencies.
2. **Jump directly to C++17**
Better long-term alignment with the Protobuf>=22 / Abseil path. Slightly
larger jump; can be a follow-up once C++14 lands.
3. **Defer until bRPC 2.x**
Raising the compile floor is closer to a toolchain requirement bump
(similar in spirit to dropping Protobuf 2.x in 1.8.0) than a major API break.
Waiting for
2.x may delay a low-risk cleanup indefinitely.
## Questions for the community
1. Is raising the minimum default to **C++14** acceptable for a 1.x release?
2. Are there known users/environments that still **must** stay on C++11 with
current bRPC?
3. Prefer **C++14 now**, or go straight to **C++17**?
4. Any objections to doing phase 1 as docs/build-only first?
Thanks for the feedback!
GitHub link: https://github.com/apache/brpc/discussions/3411
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
