Take the 2-minute tour ×

I am looking at some C code, and have noticed it is full of these curly braces surrounding blocks of code without any sort of control structure. Take a look-see:

//do some stuff . . .
fprintf(stderr, "%.2f sec\n", (float)(clock() - t) / CLOCKS_PER_SEC);
    //a block! why not?
    char *tmp_argv[3];
    tmp_argv[0] = argv[0]; tmp_argv[1] = str; tmp_argv[2] = prefix;
    t = clock();
    fprintf(stderr, "[bwa_index] Convert nucleotide PAC to color PAC... ");
    bwa_pac2cspac(3, tmp_argv);

Why would you insert blocks like this in the code? It is chock full of 'em. Is there some kind of performance benefit? Some mystical C thing? Why???

edit: This code if from BWA, a bioinformatics program that aligns small sequences to large reference ones using the Burrows-Wheeler transform, in case any of you were wondering. This code example isn't particularly relevant to the functionality of the application.

share|improve this question
The practice might have different motivations in C and C++. Your code looks like C, while your question is tagged C++. Are you sure you tagged your question correctly? –  AndreyT Nov 5 '09 at 2:05
Ah, good catch. This indeed is C. I dunno why I assumed it was C++. Changed the tag. –  Jergason Nov 5 '09 at 2:09
Then edit the text as well. It still says "I am looking at some C++ code..." –  AndreyT Nov 5 '09 at 3:45

10 Answers 10

up vote 60 down vote accepted

Legacy code needed { } in order to do declarations at all

In C89, you couldn't just do int i; anywhere; declarations were only valid at the beginning of blocks.


a = 1;
int i; /* error */
i = 2;

...wasn't valid, but

a = 1
if (e) {
  int i;

...was fine, as was a plain block.

The resulting style continued even after declarations became valid (C99) block-item(s), partly by inertia, partly for backwards portability, and also because it makes sense to establish a scope for new declarations.

share|improve this answer
+1 This answer explains the why. –  AraK Nov 5 '09 at 1:34
Strictly speaking, declaration never became statements in C. Even in C99 declarations are not statements. In C++ they are, but not in C. –  AndreyT Nov 5 '09 at 2:01
@AraK - I disagree. Based on this answer, it might the plain block idiom is no longer necessary. In fact, many people like to continue to use it to limit the scope of the variables they create, even if it is no longer necessary to do so to declare new variables in the middle of a block. I consider the scoping answer more important than the legacy answer, though C89 compatibility is also a good reason to do this (since few compilers implement C99 well). –  Chris Lutz Nov 5 '09 at 2:18
@AndreyT: Sigh, you are right, and it did bother me a bit at the time to say it that way. For the record :-) C89: compound-statement ::= { declaration-list(opt) statement-list(opt) }, whereas in C99: block-item ::= declaration | statement. –  DigitalRoss Nov 5 '09 at 3:34
And if you go back far enough in your home retrocomputing lab or virtual machine, you get just the beginning of the function block, but not inner blocks at all. –  DigitalRoss Nov 5 '09 at 3:45

To scope variables. E.g. the variable tmp_argv will only be valid between the braces.

share|improve this answer
Although it doesn't appear to be the case here, the end of scope triggers destructors which wouldn't be triggered until later otherwise. –  Keith Randall Nov 5 '09 at 1:31
@Keith: +1 I used to do this kind of thing all the time in my multi-threaded code, creating classes that would lock a mutex in their ctor and unlock it in the dtor –  Jherico Nov 5 '09 at 2:11

It is creating a scope. Stack objects are destroyed when they go out of scope. It looks like it is doing some sort of typing, which would mean each block is something that they wanted to time. However, I don't see any scoped timer objects, so, yeah, makes no sense.

share|improve this answer

The variables that you declare inside the block are local to that block. This way you may be able to redefine tmp_argv in some other place of your code (below) without conflicting with this piece of code.

share|improve this answer

A block is a scope that determines the lifetime of variables, as well as their visibility to the compiler. So variables that get created within a block go away when control exits the block.

It can be very handy when those variables are instances of classes with constructors and destructors.

However, in your example there is not much advantage.

share|improve this answer

Another use case for this I've recently discovered is when you have open/close semantics and you want to clearly mark the 'inner' code:

f = fopen('file');
    // do stuff

This works well to remind you to close/free objects and a makes the code somewhat cleaner.

share|improve this answer

Is that all of it? Maybe the programmer is using tmp_argv somewhere else in the code. I can't think of any other reason since the tmp_argv between the { and } is separate from any outside the braces.

share|improve this answer
Nope, there is a bunch more. I just grabbed a random example. –  Jergason Nov 5 '09 at 2:07
So does the programmer use tmp_argv in the scope outside the braces? –  Jacob Nov 5 '09 at 2:11

I sometimes use blocks in these cases: - To localize variables - Or to easier to read ...

share|improve this answer

Hmm - I'm maybe off the chart here but I think local variable define inside such block will not be valid outside of the block

share|improve this answer

I think it's something like a scope limiter but I'm not sure. Yes, it might be a block, if you wanna call it that.

share|improve this answer

protected by Kjuly Oct 7 at 6:48


Would you like to answer one of these unanswered questions instead?
