Google C ++ 스타일 가이드의 예외 없음 규칙;

Google C ++ 스타일 가이드의 예외 없음 규칙; STL?

---

Google의 C ++ 스타일 가이드 에는 "예외를 사용하지 않습니다"라고 나와 있습니다. 스타일은 예외 사용과 관련하여 STL을 언급하지 않습니다. STL 할당자는 실패 할 수 있으므로 컨테이너에서 발생한 예외를 어떻게 처리합니까?

1. STL을 사용하는 경우 호출자는 할당 실패를 어떻게 알 수 있습니까? push_back()또는 map 과 같은 STL 메서드는 operator[]상태 코드를 반환하지 않습니다.
2. STL을 사용하지 않는 경우 어떤 컨테이너 구현을 사용합니까?

---

그들은 말 그들은 아무도 그들을 사용해서는 안하지 않는 것이, 예외를 사용하지 마십시오. 근거를 보면 그들은 또한 다음과 같이 작성합니다.

구글의 대부분의 기존 C ++ 코드는 예외를 처리 할 준비가되어 있지 않기 때문에 예외를 생성하는 새로운 코드를 채택하는 것은 비교적 어렵습니다.

일반적인 레거시 문제. :-(

---

우리 는 최소한 애플리케이션 수준 코드에서 컨테이너가 던진 예외를 처리 하지 않습니다 .

저는 2008 년부터 Google 검색에서 C ++로 일하는 엔지니어였습니다. 우리는 STL 컨테이너를 자주 사용합니다. 저는 개인적으로 vector :: push_back () 또는 map :: operator [] 실패와 같은 것으로 추적 된 단일 주요 실패 또는 버그를 기억할 수 없습니다. 여기서 "이런, 할당이 가능하기 때문에이 코드를 다시 작성해야합니다. fail "또는"dang, 우리가 예외를 사용했다면 피할 수 있었을 것입니다. " 프로세스에 메모리가 부족한 적이 있습니까? 예, 그러나 이것은 일반적으로 간단한 실수 (예 : 누군가가 프로그램에 큰 새 데이터 파일을 추가하고 RAM 할당을 늘리는 것을 잊음) 또는 복구하고 진행할 좋은 방법이없는 치명적인 오류입니다. 우리 시스템은 이미 작업을 자동으로 관리하고 다시 시작하여 디스크, 우주선 등의 결함이있는 시스템에 견고하게 작동합니다. 이것은 실제로 다르지 않습니다.

내가 말할 수있는 한, 여기에는 문제가 없습니다.

---

나는 확신 그들이에서 예외를 사용하지 않는 것을 의미하는 것이있어 자신의 코드입니다. 당신이 그들의 확인해보세요 cpplint 스크립트를 , 당신이 (벡터, 목록, 등 등) STL 컨테이너에 대한 올바른 헤더를 포함되도록 확인 않습니다.

---

Google이 STL 및 예외에 대해 명시 적으로 언급하는 것을 발견했습니다 (강조는 제 것입니다).

자체 코드에서 예외를 사용해서는 안되지만 Visual C ++와 함께 제공되는 것을 포함하여 ATL 및 일부 STL에서 광범위하게 사용됩니다. ATL을 사용할 때 _ATL_NO_EXCEPTIONS를 정의하여 예외를 비활성화해야합니다. STL에서 예외를 비활성화 할 수도 있는지 여부를 조사해야하지만 그렇지 않은 경우 컴파일러에서 예외를 켜도 괜찮습니다. (이것은 STL을 컴파일하기위한 것입니다. 여전히 예외 처리 코드를 직접 작성해서는 안됩니다. )

나는 그러한 결정을 좋아하지 않지만 (Google에서 일하지 않는다는 점에서 운이 좋다) 그들은 그들의 행동과 의도에 대해 아주 분명합니다.

---

어쨌든 최신 운영 체제에서는 할당 실패를 처리 할 수 ​​없습니다. 성능 최적화로 일반적으로 메모리를 과도하게 할당합니다. 예를 들어, malloc()Linux에서 정말 큰 메모리 덩어리 를 호출 하여 요청 하면 실제로 백업하는 데 필요한 메모리가 없더라도 성공할 것 입니다. 커널이 실제로 페이지를 할당하려고 시도하는 것은 사용자가 액세스 할 때만 가능하며, 그 시점에서 할당이 실패했다고 말하기에는 너무 늦었습니다.

그래서:

1. 특별한 경우를 제외하고 할당 실패에 대해 걱정하지 마십시오. 시스템의 메모리가 부족하면 이는 치명적인 오류로 인해 안정적으로 복구 할 수 없습니다.

2. 그럼에도 불구하고 처리되지 않은 예외를 포착하고 e.what()출력을 기록한 다음 다시 throw추적하는 것이 좋습니다. 이는 역 추적보다 더 많은 정보를 제공 할 수 있고 일반적인 C ++ 라이브러리 구현은 자동으로 수행하지 않기 때문입니다.

3. 메모리가 부족할 때 충돌에 의존 할 수없는 방법에 대한 위의 전체 스레드는 완전하고 완전히 쓰레기입니다. C (++) 표준은이를 보장하지 않을 수 있지만 최신 시스템에서 충돌은 메모리가 부족한 경우 신뢰할 수 있는 유일한 방법 입니다. 특히 NULL할당 자로부터 C ++ 예외를 포함하고 포함하는 다른 표시를 받는 데 의존 할 수 없습니다 .

4. 페이지 0에 액세스 할 수있는 임베디드 시스템에있는 경우 해당 위치에 액세스 할 수없는 페이지를 매핑하여 문제를 해결하는 것이 좋습니다. 인간은 NULL어디에서나 포인터 를 확인하는 데 의존 할 수는 없지만 누군가가 .NET Framework를 놓쳤을 수있는 가능한 모든 (과거, 현재 및 미래) 위치 를 수정하려고 시도하는 대신 페이지를 한 번 매핑 하여 수정할 수 있습니다 .NULL

나는 당신이 어떤 종류의 사용자 지정 할당자를 사용하고 있거나 과도하게 커밋하지 않는 시스템에 있다고 말함으로써 위의 자격을 부여 할 것입니다 (스왑이없는 임베디드 시스템이 그 한 예이지만 유일한 것은 아닙니다 예). 이 경우 시스템에서 메모리 부족 상태를 정상적으로 처리 할 수 있습니다 . 그러나 일반적으로 21 세기에는 당신이 기회를 얻지 못할 것 같군요. 시스템의 메모리가 부족하다는 것을 가장 먼저 알게되는 것은 충돌이 시작될 때입니다.

---

Stl 자체는 메모리 할당 실패의 경우에만 직접 던집니다. 그러나 일반적으로 실제 응용 프로그램은 여러 가지 이유로 실패 할 수 있습니다. 메모리 할당 실패는 그중 하나입니다. 32 비트 시스템에서 메모리 할당 실패는 발생할 수 있으므로 무시할 수 없습니다. 따라서 메모리 할당 실패가 발생하지 않을 것이라는 위의 전체 논의는 무의미합니다. 이것을 가정하더라도 2 단계 초기화를 사용하여 코드를 작성해야합니다. 그리고 C ++ 예외 처리는 오랫동안 64 비트 아키텍처보다 오래되었습니다. 구글이 여기에서 보여준 부정적인 전문성을 얼마나 품위있게 다뤄야할지 모르겠고 질문에만 답해야합니다. 1997 년경 IBM의 일부 사람들이 C ++ 예외 처리의 의미를 얼마나 잘 이해하고 평가했는지에 대해 언급 한 IBM의 논문을 기억합니다. Ok 전문성은 성공의 지표가 필요하지 않습니다. 따라서 예외 처리를 포기하는 것은 STL을 사용하는 경우에만 문제가되지 않습니다. C ++를 그대로 사용하면 문제가됩니다. 포기하는 것을 의미합니다.

• 생성자 실패
• 다음 기본 / 멤버 클래스 생성자에 대한 인수로 멤버 개체 및 기본 클래스 개체를 사용할 수 있습니다 (테스트없이). 사람들이 C ++ 예외 처리가 존재하기 전에 2 단계 구성을 사용한 것은 놀라운 일이 아닙니다.
• 고객이나 제 3자가 코드를 제공 할 수있는 환경에서 계층적이고 풍부한 오류 메시지를 포기하고 오류를 발생시킵니다. 호출 코드의 원래 작성자는 호출 코드를 작성할 때 예측할 수 없었고 공간을 제공 할 수있었습니다. 그의 반환 오류 코드 범위에서.
• FlexLm 작성자가 수행 한 메시지 할당 실패에 대한 정적 메모리 개체에 대한 포인터를 반환하는 것과 같은 해킹을 방지합니다.
• 메모리 매핑 된 스파 스 파일에 주소를 반환하는 메모리 할당자를 사용할 수 있습니다. 이 경우 할당 실패는 문제의 메모리에 액세스 할 때 발생합니다. (현재 이것은 Windows에서만 작동하지만 애플은 gnu 팀이 G ++ 컴파일러에서 필요한 기능을 제공하도록 강요했습니다. 제공하려면 Linux g ++ 개발자의 압력이 더 필요합니다. 이 기능은 그들에게도 해당됩니다) (죄송합니다-이것은 STL에도 적용됩니다)
• 이 C 스타일 코딩을 우리 뒤에 남겨 둘 수 있고 (반환 값 무시) 디버그 실행 파일이있는 디버거를 사용하여 타사에서 제공하는 자식 프로세스 및 공유 라이브러리가있는 사소하지 않은 환경에서 실패하거나 원격 실행을 수행하는 것이 무엇인지 알아 내야합니다.
• stderr에 모든 것을 덤프하지 않고 풍부한 오류 정보를 호출자에게 반환 할 수 있습니다.

---

질문에 설명 된 가정 하에서 할당 실패를 처리 할 수있는 가능성은 하나뿐입니다.

• 할당자가 할당 실패시 응용 프로그램을 강제 종료합니다. 특히 이것은 cusror 할당자가 필요합니다.

인덱싱 아웃 오브 바운드 예외는 애플리케이션이 사전 검사를 사용하여 발생하지 않도록 보장 할 수 있으므로이 컨텍스트에서 덜 흥미 롭습니다.

참고 URL : https://stackoverflow.com/questions/5184115/google-c-style-guides-no-exceptions-rule-stl