复合字面量

#Original (English)

Source: https://www.mikeash.com/pyblog/friday-qa-2011-02-18-compound-literals.html

We’re back to our regular schedule at last. For today’s edition, I’m taking a break from the usual reader-driven format to discuss a topic of my own choosing: compound literals in C99.

Compound literals are a relatively unknown feature in C. They are fairly new. Introduced as part of the C99 standard in 2000, they’ve been around for a while, but for a language that dates to the 1960s, it’s a recent addition.

C99 added a lot of useful features to the language that modern Mac and iOS programmers tend to take for granted. Many of these existed as compiler extensions beforehand. Simple features like // comments, the long long type, and the ability to mix variable declarations and code are all new in C99. Compound literals are much less well known than these features, but are equally standard and can be handy, and this is why I want to talk about them today.

Compound Literal Basics Compound literals provide a way to write values of arbitrary data types in code. An expression like “hello” is a string literal that has type char *. A compound literal is simply a different kind of expression that has whatever type you’re after. For example, it’s possible to create an expression which produces the same C string as the string literal, but with explicit character-by-character construction:

1
    (char []){ 'h', 'e', 'l', 'l', 'o', '\0' }

1
    (NSSize){ 1, 2 }

Compound literal syntax closely matches variable initialization syntax. For example:

1
    NSSize s = { 1, 2 };
2
    (NSSize){ 1, 2 }; // same value
3

4
    int x[] = { 3, 4, 5 };
5
    (int []){ 3, 4, 5 }; // same

1
    Type name = { val };
2
    (Type){ val };

Basic Tricks The ability to create custom struct values is probably the most useful obvious application of compound literals. Although Cocoa takes care of its most common types with NSMakeRect and friends, there are still places to put compound literals to good use.

For example, a CGRect is really just an CGPoint and an CGSize. CGRectMake takes four discrete numbers, but sometimes it’s more convenient to just deal with those two elements. Compound literals let you do that inline:

1
    [layer setFrame: (CGRect){ origin, size }];

1
    [NSString stringWithCharacters: (unichar []){ 0x00a9 } length: 1]

1
    int *ptr;
2
    ptr = (int []){ 42 };
3
    NSLog(@"%d", *ptr);

1
    int *ptr;
2
    do {
3
        ptr = (int []){ 42 };
4
    } while(0);
5
    NSLog(@"%d", *ptr);

Mutability One really unintuitive thing about compound literals is that, unless you declare their type as const, they produce mutable values. The following is perfectly legal, albeit completely pointless, code:

1
    (int){ 0 } = 42;

For example, a common operation on sockets is to set the SO_REUSEADDR option. This tells the OS to free up the socket’s port for use as soon as the socket is closed, instead of the default behavior of waiting a few minutes first. This option is set using setsockopt. It can be used to set various parameters which need different argument types, so it simply takes a void * and a length. This is how it’s normally used to set this option:

1
    int yes = 1;
2
    setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes));

1
    setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &(int){ 1 }, sizeof(int));

Another place where this comes in handy is writing methods which take an NSError ** parameter to pass error information to the caller. By convention, it’s legal to pass NULL as the pointer to indicate that the caller doesn’t care about the error. This means that at every place where an error can occur, the pointer must be checked. This gets a bit tedious:

1
    - (BOOL)doWithError: (NSError **)error
2
    {
3
        if(fail1)
4
        {
5
            if(error)
6
                *error = [NSError ...];
7
            return NO;
8
        }
9
        if(fail2)
10
        {
11
            if(error)
12
                *error = [NSError ...];
13
            return NO;
14
        }
15
        if(fail3)
16
        {
17
            if(error)
18
                *error = [NSError ...];
19
            return NO;
20
        }
21

22
        return YES;
23
    }

1
    - (BOOL)doWithError: (NSError **)error
2
    {
3
        error = error ? error : &(NSError *){ nil };
4

5
        if(fail1)
6
        {
7
            *error = [NSError ...];
8
            return NO;
9
        }
10
        if(fail2)
11
        {
12
            *error = [NSError ...];
13
            return NO;
14
        }
15
        if(fail3)
16
        {
17
            *error = [NSError ...];
18
            return NO;
19
        }
20

21
        return YES;
22
    }

1
    - (BOOL)doWithError: (NSError **)error
2
    {
3
        error = error ? error : &(NSError *){ nil };
4

5
        BOOL success = [obj doWithError: error];
6
        if(!success)
7
        {
8
            // don't bail out if we can work around it
9
            if(![[*error domain] isEqual: CanWorkAroundDomain])
10
                return NO;
11
        }
12

13
        if(fail1)
14
        {
15
            *error = [NSError ...];
16
            return NO;
17
        }
18

19
        return YES;
20
    }

1
    #define ARRAY(...) [NSArray \
2
                         arrayWithObjects: (id []){ __VA_ARGS__ } \
3
                         count: sizeof((id []){ __VA_ARGS__ }) / sizeof(id)]

Conclusion Compound literals are a nice trick to simplify and clarify code. They are not universally applicable, and you must take care not to use them in situations where they hurt more than they help. However, they are a nice tool to have in your bag of tricks, and they help make C a little more useful and generic.

That’s it for this time. I hope to be back to my regular schedule now, so look for another post in two weeks. Until then keep sending your ideas. Friday Q&A is (usually!) driven by reader suggestions, so if you have a topic that you would like to see covered here, send it to me.