▲

Chromium에서 금지된 C++ 기능들

 (chromium.googlesource.com)
4P by GN⁺ 10시간전 | ★ favorite | 댓글 1개
  • Chromium 프로젝트는 최신 C++ 표준 기능의 사용 범위와 금지 항목을 명확히 정의해 코드 일관성과 보안성을 유지함
  • C++11~C++23까지 각 표준별로 허용·금지·검토(TBD) 상태가 구분되며, Abseil 라이브러리도 동일한 기준을 적용받음
  • 금지된 기능에는 std::shared_ptr, std::function, std::regex, std::filesystem, std::byte, char8_t, modules 등이 포함
  • 허용된 기능으로는 concepts, spaceship 연산자, designated initializer, std::to_underlying, std::ranges 알고리듬 등이 있음
  • 이 가이드는 Chromium과 하위 프로젝트 전체에 적용되며, 코드 안정성과 빌드 호환성 확보를 위한 핵심 기준으로 작동함

Chromium의 Modern C++ 사용 정책

  • Chromium은 최신 C++ 표준을 즉시 도입하지 않고, 도구체인 지원이 충분히 확보된 후 ‘초기 지원(initially supported)’ 상태로 지정
    • 이후 기능별로 허용(allowed) , 금지(banned) , 검토 중(TBD) 상태로 분류
  • 새로운 기능의 상태 변경은 cxx@chromium.org 메일링 리스트를 통해 제안 가능
  • 초기 지원 후 2년이 지나면, 명시적 검토를 거쳐 허용 또는 금지 목록으로 이동

C++11 금지 기능

  • 언어 기능: inline namespace, long long, 사용자 정의 리터럴(user-defined literals)
  • 라이브러리 기능: <chrono>, <regex>, <random> 엔진, <exception>, <ratio>, <thread> 등
    • 예외(exception)는 완전히 비활성화되어 있으며, noexcept만 허용
    • std::bind, std::function, std::shared_ptr, std::weak_ptr 대신 base::Bind, base::Callback, base::RefCounted 사용

C++17 금지 기능

  • UTF-8 문자 리터럴(u8) 금지, char8_t와의 호환성 문제 때문
  • 라이브러리 금지 항목:
    • 수학 특수함수, 병렬 알고리듬(parallel algorithms), std::any, std::byte, std::filesystem, std::pmr 메모리 리소스 등
    • 병렬 알고리듬은 libc++ 미지원 및 Chrome의 스레딩 모델과의 충돌 우려로 금지

C++20 허용 및 금지 기능

  • 허용된 언어 기능:
    • concepts, consteval, designated initializers, spaceship 연산자, [[likely]] , range-for 초기화 구문
  • 허용된 라이브러리 기능:
    • <bit>, <compare>, <concepts>, <numbers>, std::erase_if, std::ranges::subrange, std::to_underlying 등
  • 금지된 기능:
    • char8_t, modules, [[no_unique_address]] , std::bit_cast, <span>, std::bind_front, std::ranges::view_interface
  • 검토 중(TBD): coroutine, <format>, <source_location>, std::u8string

C++23 허용 및 검토 기능

  • 허용된 언어 기능: #elifdef, if consteval, 정적 연산자(static operator)
  • 허용된 라이브러리 기능: std::byteswap, std::basic_string::contains, std::to_underlying, std::ranges 확장 알고리듬
  • 검토 중 기능: std::expected, std::mdspan, std::generator, std::stacktrace, std::print, [[assume]], #warning 등

Abseil 라이브러리 정책

  • 금지된 Abseil 구성요소:
    • absl::any, absl::optional, absl::StatusOr, absl::Span, absl::FunctionRef, absl::Mutex, absl::Time, absl::btree_* 등
    • 대부분은 Chromium의 base 네임스페이스 구현체로 대체 (base::span, base::expected, base::Bind 등)
  • 검토 중(TBD): absl::linked_hash_set, absl::linked_hash_map

전반적 의미

  • Chromium은 표준 C++ 기능을 무조건 수용하지 않고, 빌드 안정성·보안·성능·코드 일관성을 기준으로 선별 적용
  • 금지된 기능 대부분은 중복 구현(base::) 또는 도구체인·ABI 호환성 문제로 인한 것
  • 이 가이드는 Chromium 생태계의 C++ 코드 품질 관리 기준서로, 오픈소스 협업 시 필수 참조 문서로 기능함
▲
GN⁺ 10시간전  [-]
Hacker News 의견들

  • 특별히 눈에 띄는 건 없지만, 대부분은 “우리 용도에 맞게 사내에서 만든 라이브러리를 쓰자”는 식의 내용임
    나머지는 로케일 문제를 피하는 등 합리적인 부분이 많음. 표준 라이브러리의 거친 부분을 다듬는 옵션들도 있어서 납득됨

    • 오래된 코드베이스를 가진 회사에서 이런 경우를 자주 봄. 예전엔 chrono가 없어서 자체 시간 타입을 만들었고, STL이 안정화되기 전부터 자체 컨테이너를 써왔음
      지금 새 프로젝트를 시작한다면 이런 규칙 대부분은 의미가 없을 것 같음
    • char8_t가 금지된 이유가 흥미로움. UTF-8이 아닌 인코딩은 거의 없고, char8_t*는 char*와 호환되지 않아서 캐스팅 난립을 막기 위해 std::string이나 std::string_view를 쓰도록 권장함
    • 10년 넘게 이 페이지를 관리했던 입장에서, 이 문서가 같은 날 r/c++와 HN에 동시에 올라온 게 신기함. 특별히 새로울 게 없는데 왜 화제가 된 건지 궁금함
    • 어떤 부분은 단순한 관성 때문이 아니라, 구글의 구현이 표준보다 엄밀히 더 나은 설계를 가지고 있어서임. 표준 타입이 더 잘 설계될 수도 있었음
    • 구글 내부엔 거의 모든 기술의 자체 버전이 있다는 인식이 있음. 문제는 일부가 그걸 맹목적으로 따라 하면서 맥락을 잃는 것임. Kubernetes를 20명 개발자에 50개 서비스 가진 조직이 도입하는 게 대표적인 예임

  • 오래된 코드 얘기를 보니 Chromium이 처음 나왔을 때가 떠오름
    벌써 20년 전에 이 코드베이스를 시작했다는 사실이 새삼 놀라움

  • <regex>가 금지된 건 잘한 결정임. UTF-8을 제대로 다루지 못해서 쓸 수가 없었음. 이런 결함 있는 설계가 표준화된 게 신기함

    • 요즘 대부분의 regex 라이브러리는 Unicode 모드를 지원함. regex 자체가 UTF-8보다 먼저 생긴 기술임

  • 상위 디렉터리에 더 흥미로운 문서들이 있음
    Chromium C++ 스타일가이드 참고할 만함

  • 예외(Exception)는 금지지만, Windows만 예외로 둠

    • 구글 코드가 원래 C 스타일 기반이라 예외 안전하지 않음. 새로 시작한다면 예외를 쓰는 게 낫겠지만, 기존 코드와의 호환성 때문에 어렵다는 설명임
      예외를 철학적으로 반대한 게 아니라, 실용적 이유로 금지한 것임. 처음부터 다시 시작한다면 다르게 했을 거라고 함
    • 이 문서는 Google Style Guide가 아니라 Chromium Modern C++ Features 문서임. 예외나 플랫폼별 내용은 다루지 않음
    • “exception”과 “Windows”를 grep 해봤는데 [[no_unique_address]] 관련 언급뿐이라, 아마 농담을 놓친 듯함

  • 금지된 기능 목록이 너무 많아서, C 전체 기능보다 많아 보임. 압도적임

    • C++은 정말 거대한 언어임

  • u8"..." 리터럴을 금지한 건 좋은 판단임. 소스 자체를 UTF-8로 쓰면 따로 접두사가 필요 없음
    이런 리터럴은 문제보다 해결책이 먼저 나온 경우임

  • 금지된 기능의 대체 방식을 찾고 싶음. 예를 들어 <filesystem>은 테스트 지원이 부족하고 보안 취약점이 있다고 함

    • 대부분의 금지 항목은 바로 옆에 대체 라이브러리가 명시되어 있음. <filesystem>만 예외임
    • 아마 Chromium 개발자 문서에 관련 정보가 있을 것 같음
    • 대체로 base/files를 사용함

  • 모듈(Modules)이 금지되어 있음. 차라리 D 언어의 모듈 시스템을 복사했으면 좋았을 것 같음

    • 그 이유는 컴파일러 지원 부족 때문임

  • 금지 목록은 “최신 기능보다 맥락이 더 중요하다”는 걸 보여줌. 작은 앱에선 문제없지만, 대규모 프로젝트에선 위험함

    • 구글의 가이드라인은 언어 전문가가 아니어도 안전하게 기여할 수 있도록 하는 게 핵심임. 즉, 프로젝트 규모보다는 조직적 일관성이 목적임
      다양한 플랫폼 간 이식성도 고려되어 있음
    • 역사적 이유나 호환성 때문에 자체 구현을 유지하는 경우도 많음. 표준화 이전부터 존재하던 기능들이라 바꾸기 어려움
    • 나도 새로운 기능을 여기저기 섞기보단, 기존 규칙에 맞춰 일관성 유지하는 게 읽는 사람 입장에서 부담이 적다고 생각함
답변달기