Why would you use the ternary operator without assigning a value for the “true” condition (x = x ?: 1)

Question

In the Android open-source qemu code I ran across this line of code:

machine->max_cpus = machine->max_cpus ?: 1; /* Default to UP */

Answer 1

This is permitted in GNU as an obscure extension to C

5.7 Conditionals with Omitted Operands

The middle operand in a conditional expression may be omitted. Then if the first operand is nonzero, its value is the value of the conditional expression.

Therefore, the expression

 x ? : y

has the value of x if that is nonzero; otherwise, the value of y.

This example is perfectly equivalent to

 x ? x : y

In this simple case, the ability to omit the middle operand is not especially useful. When it becomes useful is when the first operand does, or may (if it is a macro argument), contain a side effect. Then repeating the operand in the middle would perform the side effect twice. Omitting the middle operand uses the value already computed without the undesirable effects of recomputing it.

As you can probably guess, avoiding this is recommended for readability and portability reasons. I'm honestly surprised to see such a grammar-incompatible extension to C.

Answer 2

It's a GCC extension, and it gets more interesting and useful when the condition has side effects.

In this case, yes, I for one would agree it's obscure more than anything else.

Answer 3

Using gcc's -pedantic flag, it does say

foo.c:5: warning: ISO C forbids omitting the middle term of a ?: expression

Answer 4

I feel the other answers do not answer the question in the title and also taking the tag c into account. Therefore I add another answer.

I use this syntax to prevent my code from getting ugly through if-statements.

foo(1) == TRUE ?: error_quit("foo(1) failed");
foo(2) == TRUE ?: error_quit("foo(2) failed");
foo(3) == TRUE ?: error_quit("foo(3) failed");
foo(4) == TRUE ?: error_quit("foo(4) failed");

You can see the actual function call right in the beginning of the line. Compared it to the versions below, where the leading if obstructs the direct view of the function call.

if (foo(1) == FALSE) error_quit("foo(1)" failed");
if (foo(2) == FALSE) error_quit("foo(2)" failed");
if (foo(3) == FALSE) error_quit("foo(3)" failed");    
if (foo(4) == FALSE) error_quit("foo(4)" failed");

or even harder to read:

if (foo(1) == FALSE){
  error_quit("foo(1)" failed");
}

if (foo(2) == FALSE){
  error_quit("foo(2)" failed");
}

if (foo(3) == FALSE){
  error_quit("foo(3)" failed");
}

if (foo(4) == FALSE){
  error_quit("foo(4)" failed");
}

Answer 5

This is a GCC extension that means "if the condition is true, use it, else use this other value", so

machine->max_cpus = machine->max_cpus ?: 1;

is shorthand for

machine->max_cpus = machine->max_cpus ? machine->max_cpus : 1;

although if the conditional has side-effects, it will only be run once

Answer 6

There's another useful case for this -- the elimination of intermediate variables when calling a function or method that might return nil, that we wish to avoid calling twice. For example (Objective-C), suppose we want to unpack a file into an array if it exists, otherwise return an empty array.

- (NSArray*)hydrateBacklogFromFile:(NSString *path)
{
    NSArray *backlog = @[];
    NSData *backlogData = [NSData dataWithContentsOfFile:path];
    if (backlogData)
    {
        backlog = [NSKeyedUnarchiver unarchiveObjectWithData:backlogData] ?: backlog;
    }
    return backlog;
}

The alternatives are less concise.

- (NSArray*)hydrateBacklogFromFile:(NSString *path)
{
    NSArray *backlog = @[];
    NSData *backlogData = [NSData dataWithContentsOfFile:path];
    if (backlogData)
    {
        NSArray *tempArray = [NSKeyedUnarchiver unarchiveObjectWithData:backlogData];
        if (tempArray != nil)
        {
            backlog = tempArray;
        }
    }
    return backlog;
}

Or uglier with multiple returns etc.

- (NSArray*)hydrateBacklogFromFile:(NSString *path)
{
    NSData *backlogData = [NSData dataWithContentsOfFile:path];
    if (backlogData)
    {
        NSArray *tempArray = [NSKeyedUnarchiver unarchiveObjectWithData:backlogData];
        if (tempArray != nil)
        {
            return tempArray;
        }
    }
    return @[];
}

So it's useful syntactic sugar that I find fairly readable. The downsides are

• Implicit conversion of a pointer to a bool. This is a long-standing C convention, but most modern languages disallow it, complicating any porting efforts.

• As others have said it's also a non-standard extension, so it should be avoided if portability is a consideration at all.