2009-08-25 5 views

답변

9

가장 중요한 의미에서 bool에 대한 암시 적 변환에 의존 할 수 있습니다. C와의 하위 호환성은 그것을 요구합니다.

따라서 코드 가독성의 문제가됩니다. 종종 코드 표준의 목적은 스타일에 동의하든 그렇지 않든간에 코드 스타일에 동일성을 적용하는 것입니다. 다른 사람의 표준을보고 자신의 것으로 통합해야하는지 궁금하게 생각한다면 계속 토론하십시오. 그러나 회사의 오랜 규칙 인 경우에는 함께 배우십시오.

+0

그렇습니다. 최악의 경우 누군가가 그것을 따르는 반면 다른 사람은 그렇지 않습니다. –

+0

예, 컴파일러에서 중복 입력을 제안하는 경우에도 연산자 우선 순위에 의존 할 수있는 것처럼 암시 적 변환을 'bool'에 의존 할 수 있습니다. 괄호 (두 경우 모두 그것은 0으로 생각한다.) 규칙이 언제나 바뀔 것입니다.) bool 값을 너무 많이 오버로드하는 것과 같은 이유로 포인터를 역 참조하는 것을 잊어 버릴 때마다 암시 적 변환을 사용하여 bool에 의존 할 수도 있습니다. –

0

이것은 컴파일 된 코드에 전혀 영향을 미치지 않습니다.

유용한 점은 Java/C#과 같은 언어를 사용하는 사람들의 이해를 돕는 것입니다. 그것은 당신이 무엇을 검사하는지 더 명백하게 할 것입니다. int를 NULL과 비교하기 시작하면 경고를 던질 것입니다 (따라서 변수의 타입에 대해 흐릿함을 나타냅니다). 나는 개인적으로 첫 번째 양식을 선호하지만 완전히 부당한 요구 사항은 아닙니다.

4

대부분의 경우 끔찍하지 않지만 과 같은 의미로 정확하게 입력 할 수 있습니다.

+0

나는 즉시 참조를 찾을 수없는,하지만 난 당신이 올바른 말을 생각하지 않습니다. 나는이 표준이 NULL을 0과 같은 것으로 정의한다고 생각한다. 어느 쪽이든, 나는 그럴 수없는 단일 시스템을 명명 할 수 없었다 ... –

+0

모든 원격 표준을 따르는 시스템에서 NULL은 0 (전송까지)이다. 일부 비전 구현 코드는 포인터 0을 0 이외의 값으로 컴파일하지만 코드에서는 여전히 0입니다. –

+0

http://c-faq.com/null/ptrtest.html 동의하지 않습니다. –

0

때로는이 규칙을 위반할 수 있다고 생각합니다. bool 대신에 int을 반환하는 표준 라이브러리를 처리합니다 (C89와의 호환성을 위해).

그러나이 규칙은 일반적으로 이해하기 쉬운 코드로 연결됩니다. 심지어 C#과 같은 언어로 시행되기도하고 너무 많이 불평하지 않기 때문에이 규칙을 따르지 않는 것 외에 다른 단점도 없습니다.

0

제로 혜택을 추가하는 규칙은 수익성있게 삭제할 수있는 규칙입니다.

+2

그러나 가독성에 대한 이점도 있습니다. 네가 좋아하지 않는다고해서 그것이 위로가 아니란 뜻은 아니다. –

+0

어떻게 가독성을 향상시킬 수 있습니까? – jalf

+0

나는 그것을 싫어하는 것이 아니라, 그것이 규칙으로 존재할 유효한 이유가 있다고 생각하지 않는다. 관리 가능한 코딩 표준으로 약 40 ~ 50 개의 규칙 만 제공하므로 낭비하지 않아도됩니다. – soru

0

나는이 규칙을 매우 싫어한다. 포인터 유형 (물론 부울 유형의 경우)에 대해 bool에 암시 적 변환을 사용하는 것은 C++에서 관용적입니다. IMO,이 글을 읽을하는 것보다

bool conditionMet = false; 

while (!conditionMet) // read as "while condition is not met" 
{ 
    /* do something */ 
} 

을 훨씬 더 쉽게 읽을 수 있습니다 :

bool conditionMet = false; 

while (conditionMet == false) // read as "while conditionMet is false" 
{ 
    /* do something */ 
} 

그것은 포인터에 대한 동일합니다. 또한 불필요한 비교를 도입함으로써, 오타를 입력하고 비교 대신 과제로 끝낼 수있는 또 다른 기회가 생겨나므로 원하지 않는 결과가 발생할 수 있습니다. bool로 int를 사용하고있는 경우, 오래된 C 코드와 마찬가지로 bool에 암시 적 변환을 사용해야합니다.

+1

필자는'bool' 타입의 경우 컴파일러가 수행 할 수도 있고 수행하지 않을 수도있는 것에도 불구하고 아무 것도 강요하지 않는다고 주장 할 것입니다. 포인터 유형의 경우 조금 더 회색입니다. 다른 무엇보다도 비교 연산자를 사용해야합니다. –

5

이 규칙은 암시 적 변환이 bool (예 : std::istream) 인 클래스를 사용하려는 경우 바인드합니다.

std::ifstream file("foo.txt"); 
std::string word; 

while (file >> word) 
{ 
    // do stuff 
} 

스트림 추출 연산자가 스트림은 여전히 ​​여부를 나타내는 암시 bool로 변환되는 파일 스트림에 대한 참조를 반환 : EOF에 도달 할 때까지이 코드는 파일에서 한 번에 단어를 읽고 좋은 상태. 파일의 끝에 도달하면 테스트가 실패합니다. 귀하의 코딩 표준은 귀하가이 공통 구성을 사용하지 못하도록합니다.

포인터 유형의 경우 큰 문제는 아닙니다. 컴파일러는 bool으로의 암시 적 변환과 NULL에 대한 명시 적 테스트를 위해 거의 동일한 코드를 생성합니다. 그 시점에서 취향의 문제입니다. 어느 누구도 절대적인 의미에서 "더 나은"것은 아닙니다. 코딩 표준은 단순히 일관된 스타일을 적용하려고 시도하는 것입니다.

내장 타입 (포인터, ints 등)을 다룰 때는 반드시 코딩 표준을 따라야합니다. 합법적 인 전환이 bool 인 수업으로 위와 비슷한 상황이 발생하면 동료와 문제를 제기합니다.

+0

당신이 보여준 것과 같은 구조가 좋은 아이디어인지 아닌지에 관해서는 몇 가지 논쟁이 있음을 알아야합니다. 오버로드 된 연산자 뒤에 비 형식 변환 기능을 숨기는 것은 '깔끔한 속임수'범주에 속하지만 실제로 읽는 것이 더 쉬워 집니까? 또는 실제로 도서관의 트릭에 대해 알기 전까지는 읽기가 더 어려워 졌습니까? 마찬가지로 입력 스트림과 출력 스트림의 >> 연산자와 << 연산자도 마찬가지입니다.이 특수한 경우 비트 연산은 왜 I/O합니까? 트릭을 알기 전까지는 완전히 읽을 수 없습니다. –

+0

그것은 온라인 FAQ (http://www.parashift.com/c++-faq-lite/input-output.html#faq-15.4)에 있으며 꽤 일반적인 코드이므로 좋은 C++ 프로그래머는 이해할 수 있어야합니다. 그것. 그러나 나는 암소가 집에 올때까지 우리가 그 장점을 토론 할 수 있다고 동의합니다. :) 그것은 OP의 코딩 표준을위한 편리한 반례를 제공했습니다. –

+2

'while (static_cast (file >> word))'규칙을 따라이 기능을 사용할 수 있습니다. 이 시점에서 스타일 가이드 작성자는 "조건에서 포인터에서 부울로의 기본 * 암시 적 변환에 의존하지 마십시오."라는 규칙을 다시 언급하고자 할 수 있습니다.이 예제는 주어진 예제를 기반으로 처음 의도 된 것입니다. 또는 독자가 전환이 발생했음을 상기시키기 위해 'static_cast'가 필요하다고 생각할 수도 있습니다. 전환을 사용하려면 암시 ​​적 전환을 사용할 필요가 없습니다. –

-3

그것은 정말 바보 같은 규칙입니다.

if (ptr != NULL) // ok 

왜하지

if ((ptr != NULL)==true) 
+7

bool을 bool과 비교하는 것은 바보입니다. 상수에 대한 포인터를 비교하는 것은 그렇게 어렵습니다. –

관련 문제