check pointer by "!" - page 5

New comment
 
Alain Verleyen #:

I wasn't clear enough previously.

Either I know the pointer can only be valid or NULL. Then I will just use : if(ptr!=NULL) ...

But sometimes the pointer can be different of NULL and be invalid (as you have showed), then I will use the "full" 

I don't like to use because it's unclear and I don't know what is really done (I don't trust the documentation).

Well, you dont need to check the pointer against NULL if you are using CheckPointer().

But I am sure you know that.
 
Dominik Egert #:
Well, you dont need to check the pointer against NULL if you are using CheckPointer().

But I am sure you know that.
Yes I need to, to eventually benefit from the if shortcut.
 
Dominik Egert #:
Well, you dont need to check the pointer against NULL if you are using CheckPointer().
I thought about that too at first, but then I realized that when (pointerObj!=NULL), CheckPointer() won't be called. It seems like a unified check for all cases.
 
Vladislav Boyko #:
I thought about that too at first, but then I realized that when (pointerObj!=NULL), CheckPointer() won't be called. It seems like a unified check for all cases.

I am very careful about branches, as they are extremely expensive.

If you unequivocally call CheckPointer its a non branching code, and can mostly be fully inlined, therefore I try to stick to only one approach.

But probably its irrelevant for most use cases.

This is branching:

if(pointerObj!=NULL && CheckPointer(pointerObj)!=POINTER_INVALID) { do my stuff } ...
 
Dominik Egert #:

I am very careful about branches, as they are extremely expensive.

If you unequivocally call CheckPointer its a non branching code, and can mostly be fully inlined, therefore I try to stick to only one approach.

But probably its irrelevant for most use cases.

This is branching:

So you are suggesting to not use the if shortcut ?

I understand the concept behind what you said but I can hardly believe it's useful in practice (about if shortcut like here).

Though I would be happy to learn I am wrong. Are you able to demonstrate the impact ? (not necessarily with pointer==NULL, I don't care).

 
Dominik Egert #:

I am very careful about branches, as they are extremely expensive.

If you unequivocally call CheckPointer its a non branching code, and can mostly be fully inlined, therefore I try to stick to only one approach.

But probably its irrelevant for most use cases.

This is branching:

"do my stuff" usually means pointer accesses, so you have branching either way.

 
Vladislav Boyko #:
I thought about that too at first, but then I realized that when (pointerObj!=NULL), CheckPointer() won't be called. It seems like a unified check for all cases.

Not sure if i understood correctly, but the check against != NULL, followed by an && will end in a short circuit, if first evaluation (to the left of &&) is false. - Its the other way around for || because the result is already defined at that point.

When running code, it is often better to do the work in any case, instead of selective processing. This has to do with the pipelining of CPUs.

Clearing out the pipeline due to a faulty branch prediction is very expensive.
 
Vladislav Boyko #:

"do my stuff" usually means pointer accesses, so you have branching either way.

Yes, that is true. But also depends on your use case and how you implement your code.

I often use "empty objects" to just run through the code, and avoid branching. This can make code run significantly faster.

If you are interested in this topic, here a video:

 
Dominik Egert #:
Its the other way around for || because the result is already defined at that point.

Yes, || looks more attractive

class A {};

void doMyStuff(A*& a)
  {
   if(a == NULL || CheckPointer(a) == POINTER_INVALID)
      return;
  }
 
Vladislav Boyko #:

Yes, || looks more attractive

It's exactly the same. 
1234567
New comment