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 언어의 모듈 시스템을 복사했으면 좋았을 것 같음

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

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

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