if

[Guest]

is this line correct runtime?
------------------
if (a_class_pointer && a_class_pointer->a_member()) .....;
------------------

first check if class memory allocated (if not pointer is 0)
and then run a class member

or

first run a class member (maybe unallocated)
and then check if class memory allocated (if not crashes)

or

it is compiler depended?

 

[David Rubin]

is this line correct runtime?

This is correct.

or

first run a class member (maybe unallocated)
and then check if class memory allocated (if not crashes)

Only if you want to invoke undefined behavior.

/david

 

[Rolf Magnus]

is this line correct runtime?

Yes. The && operator first evaluates the left side, and only if it
results in true, also evaluates the right side. So the function is only
called if the pointer is not null.

 

[puppet_sock]

is this line correct runtime?

As others have stated, it's acceptable. You could rewrite this so.

if a_class_pointer
{
if a_class_pointer->a_member()
...
}

I prefer this. For example, when your "if" is not successful,
you don't know, without doing some dancing, whether it failed
due to the pointer being null or the memebr call returning false.
My way, you could put "else" cases in there.

Also, I'm usually not satisfied with a function that returns
true/false to indicate success/failure. If it's going to return
its status through its return value, I like an integer so I can
expand the possible results.
Socks

 

[Daniel T.]

is this line correct runtime?

At every point in the program where you are dereferencing a pointer, you
*must know* that the pointer is not null. How you come by that knowledge
is varied. You don't need to check every time with an 'if' statement
unless you cannot know any other way. One option would be to simply look
at the code and make sure that there is no way that the pointer could be
bad, for example:

void fn() {
char* c = new char[20];
*c = 'a'; // I just know that 'c' isn't null, I don't have to check
}

void fn( char* c ) {
if ( c )
*c = 'a'; // I know that 'c' isn't null here because
// I have an 'if' statement that ensures it
}

Of course this requires that you are able to look at *all* the relevant
code, but what if you can't? Then you can make it a design rule that
others must ensure the pointer isn't null, for example:

void fn( char* c ) {
// 'c' must not be null when calling this function
assert( c );
*c = 'a';
}

I would never do something like this:

int fn( char* c ) {
if ( !c ) return 0; // fail
*c = 'a';
return 1; // succeed
}

or any exception throwing counterpart. Instead I would use the design
rule method above. The reason is because the code calling 'fn' can
easily check to see if 'c' is null before passing it in if it doesn't
know, and it also must decide what to do in the case where 'c' is null.
Putting in the if check here simply adds useless redundancy.

first run a class member (maybe unallocated)
and then check if class memory allocated (if not crashes)

Don't ever dereference a pointer unless you know that it will be valid.

 

[Old Wolf]

is this line correct runtime?

Also, I'm usually not satisfied with a function that returns
true/false to indicate success/failure. If it's going to return
its status through its return value, I like an integer so I can
expand the possible results.

The above code is good if a_member() returns an int
(whether it be 0=success or 0=failure, we don't know what
he was trying to do).