Proposal: raise minimum C++ standard from C++11 to C++14

[darion-yaphet]

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!

[wwbmmm]

I agree that we can move to C++14.