# Chromium에서 금지된 C++ 기능들 > Clean Markdown view of GeekNews topic #26113. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26113](https://news.hada.io/topic?id=26113) - GeekNews Markdown: [https://news.hada.io/topic/26113.md](https://news.hada.io/topic/26113.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-26T04:35:15+09:00 - Updated: 2026-01-26T04:35:15+09:00 - Original source: [chromium.googlesource.com](https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/c++-features.md) - Points: 15 - Comments: 3 ## Summary Chromium은 최신 **C++ 표준 기능을 선별적으로 도입**해 코드 일관성과 보안성을 유지합니다. 각 기능은 도구체인 안정성을 기준으로 **허용·금지·검토(TBD)** 상태로 분류되며, `std::shared_ptr`, `std::function`, `std::filesystem` 등은 금지된 반면 `concepts`, `spaceship 연산자`, `std::ranges` 알고리듬 등은 허용됩니다. 이러한 정책은 Abseil 라이브러리에도 동일하게 적용되어, Chromium 생태계 전반의 **빌드 호환성과 유지보수성 확보**를 위한 핵심 기준으로 작동합니다. ## Topic Body - 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>`, ``, `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++ 코드 품질 관리 기준서**로, 오픈소스 협업 시 필수 참조 문서로 기능함 ## Comments ### Comment 49977 - Author: karikera - Created: 2026-01-27T05:21:37+09:00 - Points: 2 C++은 하위호환성을 위해서 언어가 계속 비대해지는 점이 아쉬워요.. ### Comment 49969 - Author: tsboard - Created: 2026-01-26T21:50:25+09:00 - Points: 1 정말 HN 의견 속 말처럼 거대한 언어입니다 C++ ... ### Comment 49905 - Author: neo - Created: 2026-01-26T04:35:15+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46737447) - 특별히 눈에 띄는 건 없지만, 대부분은 “우리 용도에 맞게 **사내에서 만든 라이브러리**를 쓰자”는 식의 내용임 나머지는 로케일 문제를 피하는 등 합리적인 부분이 많음. 표준 라이브러리의 거친 부분을 다듬는 옵션들도 있어서 납득됨 - 오래된 코드베이스를 가진 회사에서 이런 경우를 자주 봄. 예전엔 `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++ 스타일가이드](https://chromium.googlesource.com/chromium/src/+/main/styleguide/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 개발자 문서](https://www.chromium.org/developers)에 관련 정보가 있을 것 같음 - 대체로 `base/files`를 사용함 - 모듈(Modules)이 금지되어 있음. 차라리 **D 언어의 모듈 시스템**을 복사했으면 좋았을 것 같음 - 그 이유는 **컴파일러 지원 부족** 때문임 - 금지 목록은 “최신 기능보다 **맥락이 더 중요**하다”는 걸 보여줌. 작은 앱에선 문제없지만, 대규모 프로젝트에선 위험함 - 구글의 가이드라인은 언어 전문가가 아니어도 안전하게 기여할 수 있도록 하는 게 핵심임. 즉, 프로젝트 규모보다는 **조직적 일관성**이 목적임 다양한 플랫폼 간 **이식성**도 고려되어 있음 - 역사적 이유나 **호환성** 때문에 자체 구현을 유지하는 경우도 많음. 표준화 이전부터 존재하던 기능들이라 바꾸기 어려움 - 나도 새로운 기능을 여기저기 섞기보단, 기존 규칙에 맞춰 **일관성 유지**하는 게 읽는 사람 입장에서 부담이 적다고 생각함