mikeash.com pyblog/friday-qa-2011-02-18-compound-literals.html comments

Selvin - 2014-02-25 13:07:16

Tue, 25 Feb 2014 13:07:16 GMT



int *ptr;

    do {

        ptr = (int []){ 42 };

    } while(0);

    NSLog(@"%d", *ptr);

Neither doesn't crash nor prints junk value in Xcode 5. It just prints 42. How could it work like this?

Jean-Denis - 2012-03-29 14:41:18

Thu, 29 Mar 2012 14:41:18 GMT

I just discovered that the compiler accepts

(CGRect){ x, y, w, h}

instead of

(CGRect){{x, y}, {w, h}}

So you can "flatten" the struct.
Hopefully they behave the same.

Pier-Olivier Thibault - 2011-04-29 18:18:37

Fri, 29 Apr 2011 18:18:37 GMT

I love how someone can give credential before lecturing someone to end up being completely wrong. I'd love to know where that leaks could come from.

Steven Fisher - 2011-02-22 16:40:22

Tue, 22 Feb 2011 16:40:22 GMT

I don't like the &(int)(1), but &(int)(YES) is just as readable as the two step code. Slightly more so, actually, since I know even if the called function changes the value I don't care.

(And yeah, there's no leak. Obviously.)

mikeash - 2011-02-21 19:43:12

Mon, 21 Feb 2011 19:43:12 GMT

Would &(int){ YES } be more to your liking? I see no difference between declaring a temporary variable to hold the value and doing so for any function or method which takes an int by value. Do you declare temporary variables in all of those cases as well?

Regarding NSError, you seem to have deeply misunderstood how the whole system works. It is the standard Cocoa convention that you can pass NULL to an NSError ** parameter if you don't care about the particulars of the error. Success or failure is still signaled by use of the return value. If the caller passel NULL, you are still supposed to indicate success or failure, and you are not supposed to fail just because you pass NULL. I have no idea why you think there would be a memory leak here. I can't even begin to correct it without knowing why you think there would be, but suffice it to say that there is not.

No offense, but if you were interviewing me and you started going on about silent failures and memory leaks in a situation where they clearly do not apply, I would consider it a stroke of luck to not get the job.

jared - 2011-02-21 19:26:03

Mon, 21 Feb 2011 19:26:03 GMT

Mike, I have deep respect for you as a developer.

As a potential influencer of C-writing youth, however, this post is a bull in a china shop.



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

is neither "cleaner" nor "more readable" than the two-step alternative. The two-step example tells a maintainer what '1' means to the called function! And sure, reuseaddr might be an easy-to-remember case, but what about o_nonblock?

Your example with the NSError initializer creates a function that no-ops silently (and probably leads to a memory leak) instead of failing conspicuously. If it's supposed to output an NSError but the incoming output location is NULL, you could scarcely do worse than creating a local, fake output address.

Compound literals have a place in the world, but if I were interviewing someone and they tried to tell me how great this compound literal style is, and referenced these examples, I would consider it a mercy to yell at them before asking them to get the hell out of my office.

Chris Ryland - 2011-02-21 17:27:25

Mon, 21 Feb 2011 17:27:25 GMT

Jakob:

Well, if I see



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

then it's pretty clear that a rectangle is being constructed. If I'm not sure, then a quick click on setFrame: in Xcode will tell me.

mikeash - 2011-02-21 16:55:22

Mon, 21 Feb 2011 16:55:22 GMT

That is exactly why I wrote this post. People don't know about this syntax, despite the fact that it's useful and has been a standardized part of the language for over a decade. Now, a few more people know about it than before.

I have seen this argument pop up before and to me it sounds like an excuse not to learn. If we can't use things that most people don't use regularly, then there is no room for change or growth.

Jakob Egger - 2011-02-21 14:41:05

Mon, 21 Feb 2011 14:41:05 GMT

I think there's a good reason to use functions like NSMakeRect(): They make the code very readable. Compound literals are generally used very little. If I had to debug your code before reading this post, I'd have had no clue what this fancy syntax does. I wouldn't even have any idea where to look for the specific documentation that tells me about compound literals. If I see "NSMakeRect" somewhere, I can just click on it and XCode shows me the documentation.

In an ideal world, every developer should know every detail about every language or API they use. But in practice, I keep forgetting stuff I don't use regularily.

Jordy/Jediknil - 2011-02-20 03:52:52

Sun, 20 Feb 2011 03:52:52 GMT

Clearly the next step is to support this:

error ?= &(NSError *){ nil };

But yeah, I love the field initialization syntax that Jonathan and Jared brought up.

mikeash - 2011-02-20 00:21:32

Sun, 20 Feb 2011 00:21:32 GMT

Jared: That is nice. It should be especially nice for writing state transition tables. I have a chunk of hairy code that could be made significantly more clear using that.

Tommi: The subject of if statements and scopes came up on this blog in the comments to this post:

http://www.mikeash.com/pyblog/friday-qa-2010-01-15-stack-and-heap-objects-in-objective-c.html

I had originally stated that the if statement had its own scope, and the comments said otherwise. However, now that I actually look it up, I believe you (and my original position) are right. From my copy of a draft C standard:

A selection statement is a block whose scope is a strict subset of the scope of its enclosing block. Each associated substatement is also a block whose scope is a strict subset of the scope of the selection statement.

The term "selection statement" covers if, if/else, and switch.

Although it seems that gcc and clang will let you get away with this construct, to be completely safe you should probably write it using the conditional operator instead:

error = error ? error : &(NSError *){ nil };

Or using the gcc extension that lets you omit the middle:

error = error ?: &(NSError *){ nil };

Tommi - 2011-02-19 10:16:35

Sat, 19 Feb 2011 10:16:35 GMT

Regarding scoping I was just going to ask the same thing. Comparing the assembly output between the two cases shows no differences (gcc -std=c99 -O0) so it looks to me either both create a new scope or neither one does.

Then again, I tested with 'struct T { int i; }' rather than NSError*, maybe there's a difference there somewhere?

Jared - 2011-02-19 08:17:41

Sat, 19 Feb 2011 08:17:41 GMT

Another great trick one in the vein of Jonathan's:

int myarray[3] = { [1] = 3 }; //results in {0, 3, 0}

beautiful when you're declaring something at file scope and using enum constants for indices, because it means no more counting the lines and then comparing that to the enum values

mikeash - 2011-02-18 21:25:53

Fri, 18 Feb 2011 21:25:53 GMT

nevyn: I do read a lot, that is true. I think some of it is having a somewhat perverted mind when it comes to programming languages. I discovered the mutability of compound literals by just seeing if it worked or not, and being somewhat surprised when it did.

Johannes Fortmann: If statements don't actually create a new scope unless you also include explicit {} after it. It's safe to take the address of compound literals (and make blocks without copying them) inside a bare if.

Johannes Fortmann - 2011-02-18 20:55:06

Fri, 18 Feb 2011 20:55:06 GMT

In this example



if(!error)

    error = &(NSError *){ nil };

wouldn't the literal become invalid after the scope of the if clause is left, thus resulting in a dangling pointer just like in the "Scope" case above?

nevyn - 2011-02-18 20:50:05

Fri, 18 Feb 2011 20:50:05 GMT

It's amazing how you manage to take a subject I think I know everything about, and teach me something new about it, over and over again. Every time I tell myself I should read more docs and specs :P Is that your secret to knowing every piece of programming related knowledge in the universe?

(this time it was the mutability of the literals, that they're actually like anonymous variables. Thanks!)

Jonathan Wight - 2011-02-18 19:29:58

Fri, 18 Feb 2011 19:29:58 GMT

I think you missed my favourite trick:

someView.frame = (CGRect){ .size = someSize };

Any member you don't specify is zero-ed out for you.