nullptr NULL을 호출하지 않는 이유는 무엇입니까?

nullptr NULL을 호출하지 않는 이유는 무엇입니까?

---

C ++ 11에서는 0으로 nullptr의 이전 공통 정의에 NULL몇 가지 문제가 있기 때문에 키워드가보다 유형이 안전한 널 포인터 상수로 추가되었습니다 .

표준위원회가 새로운 널 포인터 상수를 호출하지 않기로 선택 NULL했거나 NULL이를 #defined로 선언 한 이유 는 nullptr무엇입니까?

---

Stephan T. Lavavej (C ++ 표준위원회 위원)는 한 번의 강연 에서 다음 과 같이 설명했습니다 (55:35).

구현이 허용되지만 다음 #define NULL nullptr과 같은 일부 사용이 중단됩니다.

int i = NULL;

그리고 분명히 그것들이 많이 있습니다. 그래서 그들은 변화를 강요 할 수 없었습니다.

---

nullptr은 포인터 유형 이지만 NULL정수가되는 경향이 있으며 오버로드 된 함수에서는 정수가 아닌 포인터를 사용하고 있다는 점을 분명히해야 nullptr합니다. 이것은 편리한 경우입니다.

따라서 실제로 질문에 답 NULL하고 nullptr두 가지 다른 목적을 제공하고 서로를 재정의하면 이미 존재하는 코드 기반에서 많은 것을 깨뜨릴 것입니다.

그 외에도 Bjarne Stroustrup의 웹 사이트 에서 확인하십시오 .

NULL 또는 0을 사용해야합니까?

C ++에서 NULL의 정의는 0이므로 미적인 차이 만 있습니다. 저는 매크로를 피하는 것을 선호하므로 0을 사용합니다. NULL의 또 다른 문제는 사람들이 때때로 0과 다르거 나 정수가 아니라고 잘못 생각한다는 것입니다. 사전 표준 코드에서 NULL은 때때로 부적합한 것으로 정의되었으므로 피해야합니다. 요즘은 흔하지 않습니다. 널 포인터의 이름을 지정해야하는 경우 널 포인터를 호출하십시오. 그것이 C ++ 11에서 호출되는 것입니다. 그러면 "nullptr"이 키워드가됩니다.

---

실제로 표준위원회의 토론에 참여하지 않고는 확실히 말하기 어렵지만, 충분히 호환되지 않는 NULL의미로 사용하는 일부 코드가 깨질 것이라고 생각합니다 nullptr. 그리고 오래된 코드를 깨는 것은 결코 좋은 생각이 아닙니다.

---

NULL형식이 안전하지 않습니다. 역사적인 이유로 캐스팅하지 않고 0으로 정의되었으며 컴파일러는이 특수 0에 대한 포인터로 숫자 캐스팅 경고를 침묵시킵니다.

즉시 다음을 수행 할 수 있습니다.

void* p = 0;

그러나 암시 적 캐스팅 없이는 그렇지 않습니다.

void* p = 1234;

부작용은 다른 답변이 언급했듯이 숫자 값으로 남용 될 수 있다는 것입니다.

nullptr이것을 포인터로 강제하여 개선하면 이것을 정수에 할당 할 수 없습니다. 동작이 변경되었으므로 이전 버전과의 호환성을 위해 새 이름이 생성됩니다.

또한 nullptr컴파일러에 의해 처리되므로 실제 값은 사용자에게 노출되지 않습니다 (의 경우 0과 같이 NULL). 0xdeadbeef프로그래머의 코드 로직에 영향을주지 않고 아키텍처 의존적 가치를 갖는 것이 훨씬 쉽습니다 .

---

표준위원회가 새로운 널 포인터 상수를 호출하지 않기로 선택한 이유 NULL

아마도 새로운 널 포인터가 키워드이고 키워드가 될 수 없기 #defined때문에 그것을 호출하면 NULL잘못된 형식의 C 헤더가 포함되었을 것입니다.

또는 선언 NULL해야한다 #defined에 nullptr?

표준위원회는 허용 않는 NULL것으로 #defined로 nullptr하지만, 그것을 필요로하지 않습니다.

C ++ 11 18.2 유형 [support.types] / 2 : 매크로 NULL는이 국제 표준에서 구현 정의 C ++ 널 포인터 상수입니다.

C ++ 11 4.10 포인터 변환 [conv.ptr] / 1 : 널 포인터 상수 는 0 또는 유형의 prvalue로 평가되는 정수 유형의 정수 상수 표현식 (5.19) prvalue입니다 std::nullptr_t.

이전 버전과의 호환성은 여기서 문제 가되지 않으며 NULL, 정수 형식이라고 가정하는 모든 사용은 0표준을 준수하지 않습니다. 구현은 이러한 종류의 악한 행동을 묵인하기 위해 그렇게하지 않을 수도 있습니다.

---

nullptr을 다른 유형으로 정의하는 결정이 버그 방지에 도움이되는 경우를 보여 드리겠습니다.

다음 기능을 고려하십시오.

void foo(int);
void foo(char *);

int main()
{
    foo(NULL); // oops
}

C ++ 98에서 위 코드는 foo (int) 함수를 호출합니다. NULL이 0으로 대체 되었기 때문입니다. 이는 의도 한 바가 아닐 가능성이 높습니다.

그러나 foo (nullptr) 를 호출하면 올바른 foo (char *)를 호출합니다 .

---

는 nullptr유형 안전과 (아마 사용이 아닌 포인터 타입의 초기화를 중지하는 명확성을 위해 도입 NULL).

The NULL(int type) is not changed to nullptr(pointer type) to avoid confusion and to ensure backward compatibility.

Thus, the standard committee train of thought is probably related to smooth transition from the old to new notation without causing ambiguities or braking any already existing code.

참고URL : https://stackoverflow.com/questions/32302615/why-not-call-nullptr-null