C / C ++에서 NULL 포인터 확인

C / C ++에서 NULL 포인터 확인

---

최근 코드 검토에서 기고자는 NULL포인터에 대한 모든 검사가 다음과 같은 방식으로 수행되도록 노력하고 있습니다.

int * some_ptr;
// ...
if (some_ptr == NULL)
{
    // Handle null-pointer error
}
else
{
    // Proceed
}

대신에

int * some_ptr;
// ...
if (some_ptr)
{
    // Proceed
}
else
{
    // Handle null-pointer error
}

나는 "이 포인터가 NULL이 아닌지 확인하십시오"라는 의미에서 그의 방식이 좀 더 명확하다는 데 동의하지만,이 코드를 작업하는 사람이라면 누구나 포인터 변수를 사용하는 것이 if문이 암시 적으로 검사하고 NULL있습니다. 또한 두 번째 방법은 ilk의 버그를 도입 할 가능성이 적습니다.

if (some_ptr = NULL)

그것은 찾아서 디버깅하는 데 절대적으로 고통입니다.

어떤 방법을 선호하고 왜?

---

내 경험상 양식 if (ptr)또는 시험 if (!ptr)이 선호됩니다. 그것들은 심볼의 정의에 의존하지 않습니다 NULL. 실수로 할당 할 수있는 기회를 제공하지 않습니다. 그리고 그들은 명확하고 간결합니다.

편집 : SoapBox는 주석에서 지적한 auto_ptr것처럼 포인터 역할을하고 bool정확하게이 관용구를 활성화 하기 위해 변환을 제공하는 객체 와 같은 C ++ 클래스와 호환됩니다 . 이러한 개체의 경우 명시 적 비교를 NULL수행하려면 다른 의미 부작용이 있거나 bool변환이 암시 하는 단순 존재 확인보다 비쌀 수있는 포인터로의 변환을 호출해야 합니다.

불필요한 텍스트가없는 의미를 나타내는 코드를 선호합니다. 중복 특이성 if (ptr != NULL)과 동일한 의미를 지니고 if (ptr)있습니다. 다음 논리는 글을 쓰는 if ((ptr != NULL) == TRUE)것이고, 그런 식으로 광기가 있습니다. C 언어는 부울 테스트 분명하다 if, while나 아닌 값의 의미 특정을 가지고 같은 사실과 제로는 false입니다. 중복성은 명확하지 않습니다.

---

if (foo)충분히 명확하다. 사용해.

---

이것부터 시작하겠습니다 : 일관성이 중요합니다. 결정은 코드베이스의 일관성보다 중요하지 않습니다.

C ++에서

C ++에서 NULL은 0 또는 0L로 정의됩니다.

C ++ Programming Language Bjarne Stroustrup을0NULL 읽으면 할당을 할 때 매크로 를 피하기 위해 명시 적으로 사용하는 것이 좋습니다. 비교와 똑같이했는지 확실하지 않습니다. 책을 읽은 지 오래되었습니다. if(some_ptr)명백한 비교가 없지만 나는 그것에 모호합니다.

그 이유는 NULL매크로가 (거의 모든 매크로와 마찬가지로) 기만적이기 때문에 실제로 0문자 그대로이며 이름에서 알 수 있듯이 고유 한 유형이 아닙니다. 매크로를 피하는 것은 C ++의 일반적인 지침 중 하나입니다. 반면에 0정수처럼 보이며 포인터와 비교하거나 포인터에 할당 할 때는 그렇지 않습니다. 개인적으로 나는 어느 쪽이든 갈 수 있지만 일반적으로 나는 명백한 비교를 건너 뜁니다 (일부 사람들은 이것을 싫어하기 때문에 아마도 변경 사항을 제안하는 기고자가있는 것입니다).

개인적인 감정에 관계없이 이것은 올바른 방법이 없기 때문에 가장 악한 선택입니다.

이것은 명확하고 일반적인 관용구이며 선호합니다. 비교 중에 실수로 값을 할당 할 가능성이 없으며 명확하게 읽습니다.

if(some_ptr){;}

이것이 some_ptr포인터 유형 이라는 것을 알면 분명 하지만 정수 비교처럼 보일 수도 있습니다.

if(some_ptr != 0){;}

이것은 명백한 일이며, 일반적인 경우에 의미가 있습니다 ... 그러나 유출 된 추상화 NULL이며 실제로 0문자 그대로이며 쉽게 오용 될 수 있습니다.

if(some_ptr != NULL){;}

C ++ 0x에는 nullptr이있어 명시적이고 정확하므로 선호되는 방법입니다. 우연히 할당하는 것에주의하십시오.

if(some_ptr != nullptr){;}

C ++ 0x로 마이그레이션 할 수있을 때 까지이 방법 중 어느 것이 사용되는지 걱정하는 데 시간 낭비라고 주장 할 수 있습니다. 완전히 전달 된 일반적인 프로그래밍 문제와 함께 nullptr이 발명 된 이유는 모두 충분하지 않습니다 .) 가장 중요한 것은 일관성을 유지하는 것입니다.

C에서

C는 다른 짐승입니다.

In C NULL can be defined as 0 or as ((void *)0), C99 allows for implementation defined null pointer constants. So it actually comes down to the implementation's definition of NULL and you will have to inspect it in your standard library.

Macros are very common and in general they are used a lot to make up for deficiencies in generic programming support in the language and other things as well. The language is much simpler and reliance on the pre-processor more common.

From this perspective I'd probably recommend using the NULL macro definition in C.

---

I use if (ptr), but this is completely not worth arguing about.

I like my way because it's concise, though others say == NULL makes it easier to read and more explicit. I see where they're coming from, I just disagree the extra stuff makes it any easier. (I hate the macro, so I'm biased.) Up to you.

I disagree with your argument. If you're not getting warnings for assignments in a conditional, you need to turn your warning levels up. Simple as that. (And for the love of all that is good, don't switch them around.)

Note in C++0x, we can do if (ptr == nullptr), which to me does read nicer. (Again, I hate the macro. But nullptr is nice.) I still do if (ptr), though, just because it's what I'm used to.

---

Frankly, I don't see why it matters. Either one is quite clear and anyone moderately experienced with C or C++ should understand both. One comment, though:

If you plan to recognize the error and not continue executing the function (i.e., you are going to throw an exception or return an error code immediately), you should make it a guard clause:

int f(void* p)
{
    if (!p) { return -1; }

    // p is not null
    return 0;
}

This way, you avoid "arrow code."

---

Personally I've always used if (ptr == NULL) because it makes my intent explicit, but at this point it's just a habit.

Using = in place of == will be caught by any competent compiler with the correct warning settings.

The important point is to pick a consistent style for your group and stick to it. No matter which way you go, you'll eventually get used to it, and the loss of friction when working in other people's code will be welcome.

---

Just one more point in favor of the foo == NULL practice: If foo is, say, an int * or a bool *, then the if (foo) check can accidentally be interpreted by a reader as testing the value of the pointee, i.e. as if (*foo). The NULL comparison here is a reminder that we're talking about a pointer.

But I suppose a good naming convention makes this argument moot.

---

Actually, I use both variants.

There are situations, where you first check for the validity of a pointer, and if it is NULL, you just return/exit out of a function. (I know this can lead to the discussion "should a function have only one exit point")

Most of the time, you check the pointer, then do what you want and then resolve the error case. The result can be the ugly x-times indented code with multiple if's.

---

The C Programming Language (K&R) would have you check for null == ptr to avoid an accidental assignment.

---

If style and format are going to be part of your reviews, there should be an agreed upon style guide to measure against. If there is one, do what the style guide says. If there's not one, details like this should be left as they are written. It's a waste of time and energy, and distracts from what code reviews really ought to be uncovering. Seriously, without a style guide I would push to NOT change code like this as a matter of principle, even when it doesn't use the convention I prefer.

And not that it matters, but my personal preference is if (ptr). The meaning is more immediately obvious to me than even if (ptr == NULL).

Maybe he's trying to say that it's better to handle error conditions before the happy path? In that case I still don't agree with the reviewer. I don't know that there's an accepted convention for this, but in my opinion the most "normal" condition ought to come first in any if statement. That way I've got less digging to do to figure out what the function is all about and how it works.

The exception to this is if the error causes me to bail from the function, or I can recover from it before moving on. In those cases, I do handle the error first:

if (error_condition)
  bail_or_fix();
  return if not fixed;

// If I'm still here, I'm on the happy path

By dealing with the unusual condition up front, I can take care of it and then forget about it. But if I can't get back on the happy path by handling it up front, then it should be handled after the main case because it makes the code more understandable. In my opinion.

But if it's not in a style guide then it's just my opinion, and your opinion is just as valid. Either standardize or don't. Don't let a reviewer pseudo-standardize just because he's got an opinion.

---

I think this is quite clear:

if( !some_ptr )
{
  // handle null-pointer error
}
else
{
  // proceed
}

Read it as "If there is no pointer ..."

Additionally it is concise and has no danger of accidental assignments.

---

This is one of the fundamentals of both languages that pointers evaluate to a type and value that can be used as a control expression, bool in C++ and int in C. Just use it.

---

• Pointers are not booleans
• Modern C/C++ compilers emit a warning when you write if (foo = bar) by accident.

Therefore I prefer

if (foo == NULL)
{
    // null case
}
else
{
    // non null case
}

or

if (foo != NULL)
{
    // non null case
}
else
{
    // null case
}

However, if I were writing a set of style guidelines I would not be putting things like this in it, I would be putting things like:

Make sure you do a null check on the pointer.

---

I'm a huge fan of the fact that C/C++ doesn't check types in the boolean conditions in if, for and while statements. I always use the following:

if (ptr)

if (!ptr)

even on integers or other type that converts to bool:

while(i--)
{
    // Something to do i times
}

while(cin >> a >> b)
{
    // Do something while you've input
}

Coding in this style is more readable and clearer to me. Just my personal opinion.

Recently, while working on OKI 431 microcontroller, I've noticed that the following:

unsigned char chx;

if (chx) // ...

is more efficient than

if (chx == 1) // ...

because in later case the compiler has to compare the value of chx to 1. Where chx is just a true/false flag.

---

Most compilers I've used will at least warn on the if assignment without further syntax sugar, so I don't buy that argument. That said, I've used both professionally and have no preference for either. The == NULL is definitely clearer though in my opinion.

참고URL : https://stackoverflow.com/questions/3825668/checking-for-null-pointer-in-c-c